Network Working Group B. Lilly Internet-Draft July 2005 Updates: 2369, 2919 (if approved) Intended status: Standards Track Expires: January 11, 2006 Extensible Message Application Interchange Language (EMAIL) -- Part Four: Message/List Registration draft-lilly-extensible-internet-message-format-p04-00 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo defines and provides registration information for a media type for conveying mailing list information in the extensible message format. Lilly Expires January 11, 2006 [Page 1] Internet-Draft EMAIL Part 4: Message/List July 2005 Table of Contents 1. Introduction.................................................... 3 2. Semantics....................................................... 3 2.1. Syntax..................................................... 3 2.2. Media Type Registration.................................... 4 3. Security Considerations......................................... 7 4. Internationalization Considerations............................. 7 5. IANA Considerations............................................. 7 Appendix A. Disclaimers............................................ 7 Normative References............................................... 8 Informative References............................................. 8 Author's Address................................................... 8 Lilly Expires January 11, 2006 [Page 2] Internet-Draft EMAIL Part 4: Message/List July 2005 1. Introduction This memo will introduce a new media type which is used in the construction of an extensible message format. Semantics of the media type will be presented in prose, syntax will be presented in ABNF format [N1.RFC2234] as amended by [N2.Errata] where applicable with accompanying normative prose, incorporating keywords defined in [N3.BCP14], and media type registration data will be presented using the form specified in [I1.MediaReg]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD", "SHOULD NOT" "RECOMMENDED" "MAY" and "OPTIONAL" in this document are to be interpreted as described in [N3.BCP14]. 2. Semantics The message/list media type denotes a set of optional fields and optional free-form text pertaining to mailing list recipient expansion of a message. 2.1. Syntax The general syntax follows message media syntax as specified in section 5.2 of [N4.RFC2046]. The media type consists of zero or more fields, an empty line if there is non-field content, and optional non-field content. Multiple instances of message/list are permissible within multipart/email, corresponding to separate expansions by mailing lists. The fields may include any of the fields specified in [N5.RFC2369] and/or [N6.RFC2919], as well as MIME fields including MIME extension fields, but excluding the MIME- Version field [N7.RFC2045]. Syntax for MIME and MIME fields is provided in the relevant specifications. Unfortunately, no formal syntax specification is provided in [N5.RFC2369] so a formal syntax is included below. 2.1.1. ABNF list-id = MIME-field = obs-ws = [FWS] ; FWS per RFC 2822, SHOULD parse, MUST ; NOT generate URI = br-URI = "<" obs-ws URI obs-ws ">" br-URI-list = br-URI *([CFWS] "," [CFWS] br-URI) list-help = "List-Help:" [CFWS] br-URI-list [CFWS] list-unsubscribe = "List-Unsubscribe:" [CFWS] br-URI-list [CFWS] Lilly Expires January 11, 2006 [Page 3] Internet-Draft EMAIL Part 4: Message/List July 2005 list-subscribe = "List-Subscribe:" [CFWS] br-URI-list [CFWS] list-post = "List-Subscribe:" ; see RFC 2369 regarding [CFWS] (br-URI-list ; the unregistered "NO" / "NO") [CFWS] ; keyword list-owner = "List-Owner:" [CFWS] br-URI-list [CFWS] list-archive = "List-Archive:" [CFWS] br-URI-list [CFWS] list-field = list-help / list-unsubscribe / list-subscribe / list-post / list-owner / list-archive / list-id original-return-path = "Original-Return-Path:" path ; path per RFC ; 2822 message-list = *(list-field / MIME-field / ; multipart-body original-return-path) [CRLF ; per RFC 2046, (multipart-body / ; text per RFC 1*(*998text CRLF))] ; 2822 See [N8.RFC2822], [N4.RFC2046], [N6.RFC2919], [N7.RFC2045], MIME extension field specifications, and URI specifications for details of grammar rules incorporated in the ABNF above. 2.1.2. Original-Return-Path field The optional Original-Return-Path field records the message SMTP return path prior to any change made by the list expander. It permits tracing the order of list expansions where multiple expansions occur. The field should appear only in the header of the message/list media type; it should not appear in the overall message header. 2.2. Media Type Registration Type name: message Subtype name: list Required parameters: version: An unsigned decimal integer number indicating the version of the media type specification. The value corresponding to this specification is 1. A version value change requires a new specification. A specification revision entailing any of the following means that a new version is REQUIRED: o addition of a mandatory part Lilly Expires January 11, 2006 [Page 4] Internet-Draft EMAIL Part 4: Message/List July 2005 o specification such that existence or content of some part affects processing or display of the message as a whole or of any part other than the specific part whose existence or content is concerned Once a mandatory part is added to the specification (with a corresponding new version), that part MUST NOT subsequently be made optional. That prohibition is necessary to ensure backward compatibility of new versions. Consequently, addition of a mandatory part is a change that should not be made lightly. Sequence: An unsigned decimal integer number indicating the sequence of detected list expansions. Optional parameters: none Encoding considerations: Encoding MUST be one of 7bit, 8bit, or binary per section 6.4 of [N7.RFC2045] and section 5.1 of [N4.RFC2046]. Non-field text in some charsets (with a suitable Content-Type field specifying the MIME-compatible charset in a "charset" parameter of the Content-Type field) or non-field MIME content may require 8bit or binary transport. Such requirements should be avoided where practicable, but must be labeled appropriately per [N7.RFC2045] and [N4.RFC2046] where used. Restrictions on usage: none, but the primary expected usage is within a multipart/email wrapper Security considerations: Making it easier for users and applications to find specific information necessarily makes it easier for attackers to find such information. Separating the end-to-end message information from transport markings facilitates digital signing and/or encryption of that communication, including header information, impeding eavesdropping and similar attacks. It facilitates confidentiality, data integrity, and data origin authentication when used with message security mechanisms applied to the end-to-end message contained within the wrapper. This media type itself may be forged or altered in transport unless some suitable integrity protection is provided external to the media type. This media type does not address security issues such as inappropriate usage and denial of service. Interoperability considerations: Conforming legacy MIME implementations will interpret the message/list media type as application/octet-stream. Because of the possibility of a message being processed by a mix of list expanders which do and do not recognize this media type, the following recommendations apply: Lilly Expires January 11, 2006 [Page 5] Internet-Draft EMAIL Part 4: Message/List July 2005 o List expanders should utilize the media type for messages of type multipart/email and should also include the List-fields in the message header for use by legacy list expanders and UAs in accordance with [N5.RFC2369] and [N6.RFC2919]. o List expanders MUST NOT alter a message/list component inserted by a different list expander. They MAY modify fields in the overall message header as permitted by [N5.RFC2369] and/or [N6.RFC2919]. Indeed, modification of any existing MIME component is prohibited by the MIME specification. o List expanders inserting a message/list component MUST set the "sequence" parameter in accordance with the content of the message prior to expansion. That is, if there are no prior message/list components, the sequence number would be set to 1, otherwise to one higher than the highest existing message/list component sequence number. o List expanders SHOULD insert an Original-Return-Path field in the message/list component added to facilitate manual tracing of multiple list expansions. o Humans and software tracing multiple list expansions should do so cautiously; sequence numbers will not incorporate list expansions which do not use the message/list media type, and due to modifications of the message header tracing of expansions will be difficult. Published specification: This document. Applications which use this media type: Any applications using MIME and the extensible message format. Additional information: Magic number(s): None File extension(s): Files do not require any specific "extension" or suffix. Many are in use as a convenience for mechanized processing of files. File names are orthogonal to the nature of the content. In particular, while a file name or a component of a name may be useful in some types of automated processing of files, the name or component might not be capable of indicating subtleties. This media type SHOULD NOT be assigned a relationship with any file "extension" where content may be untrusted unless there is provision for human judgment which may be used to override that relationship for individual files. Where appropriate, a filename MAY be suggested by a suitable mechanism such as the one specified in [I2.RFC2183] as amended by [I3.RFC2231] and [N2.Errata]. Macintosh File Type Code(s): unknown Lilly Expires January 11, 2006 [Page 6] Internet-Draft EMAIL Part 4: Message/List July 2005 Person & email address to contact for further information: Bruce Lilly blilly@erols.com Intended usage: COMMON, although the primary use will be within the multipart/email type of the extensible message format Author/Change controller: IESG 3. Security Considerations Security considerations relevant to the media type are discussed in the media type registration form data in this memo. 4. Internationalization Considerations Internationalization considerations may impose encoding constraints as discussed in section 1 of this memo. 5. IANA Considerations Upon approval by the IESG, IANA SHALL register the media type defined in this document. It is intended that a future revision of this document may specify registration of the Original-Return-Path field. Appendix A. Disclaimers This document has exactly one (1) author. In spite of the fact that the author's given name may also be the surname of other individuals, and the fact that the author's surname may also be a given name for some females, the author is, and has always been, male. The presence of "or she", "/SHE", "each", "their", and "authors" (plural) in the boilerplate sections of this document is irrelevant. As noted in the "Status of this Memo" section, this document is an Internet-Draft, and as such is a "work in progress", not a standard. Reference to this document's contents as "this standard" in the boilerplate are inappropriate. The author of this document is not responsible for the boilerplate text. Comments regarding the silliness, lack of accuracy, and lack of precision of the boilerplate text should be directed to the IESG, not to the author. Lilly Expires January 11, 2006 [Page 7] Internet-Draft EMAIL Part 4: Message/List July 2005 Normative References [N1.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [N2.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html [N3.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [N4.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [N5.RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. [N6.RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001. [N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [N8.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Informative References [I1.MediaReg] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures" (draft-freed-media-type-reg-04.txt), April 2005. [I2.RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [I3.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. Author's Address Bruce Lilly Email: blilly@erols.com Full Copyright Statement Copyright (C) The Internet Society (2005). Lilly Expires January 11, 2006 [Page 8] Internet-Draft EMAIL Part 4: Message/List July 2005 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 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 Statement 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 currently provided by the Internet Society. Lilly Expires January 11, 2006 [Page 9]