idnits 2.17.1 draft-welzl-expires-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2008) is 5750 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft M. Welzl 2 Intended status: Proposed Standard University of Innsbruck 3 Expires: January 31, 2009 T. Nolf 4 University of Innsbruck 5 J. Palme 6 Stockholm University / KTH 7 July 30, 2008 9 The Expires Header in E-mail 10 draft-welzl-expires-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 31, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This memo introduces a new email header called Expires. Using this 44 header, the sender of an email can state that (s)he believes this 45 message will be irrelevant after the indicated date/time. The 46 receiving MUA can then automatically detect that a message has 47 expired and facilitate handling of such emails for the user. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119 [i]. 55 The word "client" may in this text designate functionality, which 56 some implementations actually implement wholly or partly in a server. 57 For example, in the case of IMAP and NNTP, it is very common to 58 implement functionality, which logically may be regarded as belonging 59 to a client, in the server. 61 The acronym "MUA" is short for "mail user agent", the software that 62 allows a user to access and manage email. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Syntax.........................................................2 68 3. Semantics......................................................2 69 4. Relation to X.400 gateways and Netnews.........................3 70 Security Considerations...........................................3 71 References........................................................3 72 Acknowledgments...................................................4 73 Author's Addresses................................................4 75 1. Introduction 77 This memo introduces a new header field called "Expires" for Internet 78 email [1] headers, which will enhance the email service. The 79 intention is to let a sender of an email state a date/time until 80 which a message will be relevant. Using this header field, the 81 receiving MUA can then automatically detect that a message has 82 expired and facilitate handling of such emails for the user. 84 2. Syntax 86 This section specifies the syntax of the new field using the ABNF 87 rules from [2]. The syntax elements are defined in [1]. 89 Expires-field = "Expires:" CFWS date-time [CFWS] CRLF 91 3. Semantics 93 The Expires header indicates a date-time at which this message 94 expires. The exact meaning of "expires" is: 96 "The sender believes this message will be irrelevant after the 97 indicated date/time." 99 This header is intended for use between senders and recipients and 100 their agents, rather than by message transport. It is suggested that 101 the default behavior of an MUA with respect to the expires header 102 field should be to display such a message in a distinguished way. For 103 example, the message could be displayed with gray text rather than 104 black, or in a different font than normal, or (in summaries) with an 105 image of an hourglass with the sand at the bottom. 107 It is also suggested that MUAs allow setting of an expiration date as 108 an option when composing messages. 110 The Expires header is strictly advisory in nature: MUAs, Message 111 Stores, and MTAs, MUST NOT delete a message on the basis of an 112 Expired header field unless given explicit instructions to do so by 113 the recipient. Mail Filters MUST NOT consider an expired header field 114 as criteria to be considered for deleting the message unless given 115 explicit instructions to do so by the recipient. 117 4. Relation to X.400 gateways and Netnews 119 A similar header to Expires is also defined in recommendations for 120 gatewaying [3] between X.400 [4] and Internet mail as a renamed 121 version of what was previously called "Expiry-Date". However, those 122 recommendations are only valid for gateways. By defining the field 123 here, it is made available for general Internet email usage. It is 124 additionally defined in a similar way in netnews [5]. 126 Note that the definition given in this document imposes a stricter 127 requirement on the field to be advisory than the other definitions: 128 in [3], the meaning of Expiry is specified as the "time at which a 129 message loses its validity", and [5] states that the Expires header 130 field "specifies a date and time when the poster deems the article to 131 be no longer relevant and could usefully be removed". Such automatic 132 removal without explicit instructions from the recipient is strictly 133 forbidden for general Internet mail. 135 Security Considerations 137 One intention of "Expires" is to help recipients avoid seeing 138 messages with information which is not any longer valid. There 139 may of course be cases where a user might want to see an expired 140 message (e.g. a user might sometimes want to be informed of a 141 meeting, even after the time of the meeting). This is the reason for 142 the requirement that MUAs MUST NOT delete messages on the basis of 143 the Expires-field unless given explicit instructions to do so by the 144 recipient. 146 References 148 [1] Resnick, P. (Editor), "Internet Message Format", Internet-draft 149 draft-resnick-2822upd-06 (work in progress), February 2008. 150 EDITORIAL NOTE: TO BE REPLACED WITH RFC 2822 IN CASE OF 151 PUBLICATION BEFORE THIS I-D IS PUBLISHED. 153 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 154 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 155 Demon Internet Ltd., November 1997. 157 [3] Kille, S. and Overell, P.(Editors), "MIXER (Mime Internet X.400 158 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", 159 RFC 2156, January 1998. 161 [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal 162 Messaging System, ISO international standard 10021-7, ITU 163 recommendation X.420. 165 [5] Murchison, K. (Editor), Lindsey, C., Kohn, D., "Netnews Article 166 Format", Internet-draft draft-ietf-usefor-usefor-12 (work in 167 progress), January 2007. 168 EDITORIAL NOTE: TO BE REPLACED WITH RFC 1036 IN CASE OF 169 PUBLICATION BEFORE THIS I-D IS PUBLISHED. 171 Acknowledgments 173 The authors would like to thank the many people who provided their 174 help during fruitful discussions in the IETF-822 mailing list of the 175 internet mail consortium. This includes Frank Ellermann, Ned Freed, 176 Arnt Gulbrandsen, Charles Lindsey, Jeff Macdonald, Keith Moore and 177 Hector Santos. Specifically, Keith Moore provided text for the 178 semantic definition of Expiry. 180 Author's Addresses 182 Michael Welzl 183 University of Innsbruck 184 Technikerstr. 21 A 185 A-6020 Innsbruck 186 Austria 188 Phone: +43 (512) 507-6110 189 Email: michael.welzl@uibk.ac.at 191 Thomas Nolf 192 University of Innsbruck 193 Technikerstr. 21 A 194 A-6020 Innsbruck 195 Austria 197 Email: thomas.nolf@student.uibk.ac.at 199 Jacob Palme 200 Stockholm University / KTH 201 Skeppargatan 73 202 S-115 30 Stockholm 203 Sweden 205 Email: jpalme@dsv.su.se 207 Full Copyright Statement 209 This document is subject to the rights, licenses and restrictions 210 contained in BCP 78, and except as set forth therein, the authors 211 retain all their rights. 213 This document and the information contained herein are provided on an 214 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 215 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 216 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 217 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 221 Intellectual Property 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use 235 of such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at 243 ietf-ipr@ietf.org. 245 Acknowledgment 247 Funding for the RFC Editor function is provided by the IETF 248 Administrative Support Activity (IASA).