Internet-Draft M. Welzl Intended status: Proposed Standard University of Innsbruck Expires: January 31, 2009 T. Nolf University of Innsbruck J. Palme Stockholm University / KTH July 30, 2008 The Expires Header in E-mail draft-welzl-expires-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo introduces a new email header called Expires. Using this header, the sender of an email can state that (s)he believes this message will be irrelevant after the indicated date/time. The receiving MUA can then automatically detect that a message has expired and facilitate handling of such emails for the user. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. The word "client" may in this text designate functionality, which some implementations actually implement wholly or partly in a server. For example, in the case of IMAP and NNTP, it is very common to Welzl, Nolf, Palme Expires - January 2008 [Page 1] The Expires Header in E-mail July 2008 implement functionality, which logically may be regarded as belonging to a client, in the server. The acronym "MUA" is short for "mail user agent", the software that allows a user to access and manage email. Table of Contents 1. Introduction...................................................2 2. Syntax.........................................................2 3. Semantics......................................................2 4. Relation to X.400 gateways and Netnews.........................3 Security Considerations...........................................3 References........................................................3 Acknowledgments...................................................4 Author's Addresses................................................4 1. Introduction This memo introduces a new header field called "Expires" for Internet email [1] headers, which will enhance the email service. The intention is to let a sender of an email state a date/time until which a message will be relevant. Using this header field, the receiving MUA can then automatically detect that a message has expired and facilitate handling of such emails for the user. 2. Syntax This section specifies the syntax of the new field using the ABNF rules from [2]. The syntax elements are defined in [1]. Expires-field = "Expires:" CFWS date-time [CFWS] CRLF 3. Semantics The Expires header indicates a date-time at which this message expires. The exact meaning of "expires" is: "The sender believes this message will be irrelevant after the indicated date/time." This header is intended for use between senders and recipients and their agents, rather than by message transport. It is suggested that the default behavior of an MUA with respect to the expires header field should be to display such a message in a distinguished way. For Welzl, Nolf, Palme Expires - January 2008 [Page 2] The Expires Header in E-mail July 2008 example, the message could be displayed with gray text rather than black, or in a different font than normal, or (in summaries) with an image of an hourglass with the sand at the bottom. It is also suggested that MUAs allow setting of an expiration date as an option when composing messages. The Expires header is strictly advisory in nature: MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis of an Expired header field unless given explicit instructions to do so by the recipient. Mail Filters MUST NOT consider an expired header field as criteria to be considered for deleting the message unless given explicit instructions to do so by the recipient. 4. Relation to X.400 gateways and Netnews A similar header to Expires is also defined in recommendations for gatewaying [3] between X.400 [4] and Internet mail as a renamed version of what was previously called "Expiry-Date". However, those recommendations are only valid for gateways. By defining the field here, it is made available for general Internet email usage. It is additionally defined in a similar way in netnews [5]. Note that the definition given in this document imposes a stricter requirement on the field to be advisory than the other definitions: in [3], the meaning of Expiry is specified as the "time at which a message loses its validity", and [5] states that the Expires header field "specifies a date and time when the poster deems the article to be no longer relevant and could usefully be removed". Such automatic removal without explicit instructions from the recipient is strictly forbidden for general Internet mail. Security Considerations One intention of "Expires" is to help recipients avoid seeing messages with information which is not any longer valid. There may of course be cases where a user might want to see an expired message (e.g. a user might sometimes want to be informed of a meeting, even after the time of the meeting). This is the reason for the requirement that MUAs MUST NOT delete messages on the basis of the Expires-field unless given explicit instructions to do so by the recipient. Welzl, Nolf, Palme Expires - January 2008 [Page 3] The Expires Header in E-mail July 2008 References [1] Resnick, P. (Editor), "Internet Message Format", Internet-draft draft-resnick-2822upd-06 (work in progress), February 2008. EDITORIAL NOTE: TO BE REPLACED WITH RFC 2822 IN CASE OF PUBLICATION BEFORE THIS I-D IS PUBLISHED. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [3] Kille, S. and Overell, P.(Editors), "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal Messaging System, ISO international standard 10021-7, ITU recommendation X.420. [5] Murchison, K. (Editor), Lindsey, C., Kohn, D., "Netnews Article Format", Internet-draft draft-ietf-usefor-usefor-12 (work in progress), January 2007. EDITORIAL NOTE: TO BE REPLACED WITH RFC 1036 IN CASE OF PUBLICATION BEFORE THIS I-D IS PUBLISHED. Acknowledgments The authors would like to thank the many people who provided their help during fruitful discussions in the IETF-822 mailing list of the internet mail consortium. This includes Frank Ellermann, Ned Freed, Arnt Gulbrandsen, Charles Lindsey, Jeff Macdonald, Keith Moore and Hector Santos. Specifically, Keith Moore provided text for the semantic definition of Expiry. Welzl, Nolf, Palme Expires - January 2008 [Page 4] The Expires Header in E-mail July 2008 Author's Addresses Michael Welzl University of Innsbruck Technikerstr. 21 A A-6020 Innsbruck Austria Phone: +43 (512) 507-6110 Email: michael.welzl@uibk.ac.at Thomas Nolf University of Innsbruck Technikerstr. 21 A A-6020 Innsbruck Austria Email: thomas.nolf@student.uibk.ac.at Jacob Palme Stockholm University / KTH Skeppargatan 73 S-115 30 Stockholm Sweden Email: jpalme@dsv.su.se Welzl, Nolf, Palme Expires - January 2008 [Page 5] The Expires Header in E-mail July 2008 Full Copyright Statement This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Welzl, Nolf, Palme Expires - January 2008 [Page 6]