Network Working Group B. Lilly Internet-Draft July 2005 Intended status: Informational Expires: January 10, 2006 Extensible Message Application Interchange Language (EMAIL) -- Part One: Introduction and Overview draft-lilly-extensible-internet-message-format-p01-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 will present a brief history of the Internet Message Format evolution, will identify problems caused by changes that have been made, and will introduce terminology and concepts that will be used in other documents in the series. Lilly Expires January 10, 2006 [Page 1] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 Table of Contents 1. Introduction.................................................... 3 1.1. A Brief History of the Internet Message Format............. 3 1.2. Other Directions........................................... 4 2. Goals........................................................... 4 3. Mechanism, Implementation Overview, and Notation................ 4 4. Compatibility................................................... 5 5. Extensibility Roadmap........................................... 5 6. Security Considerations......................................... 5 7. Internationalization Considerations............................. 6 8. IANA Considerations............................................. 6 Appendix A. Disclaimers............................................ 6 Informative References............................................. 6 Author's Address................................................... 8 Lilly Expires January 10, 2006 [Page 2] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 1. Introduction 1.1. A Brief History of the Internet Message Format The origin of Internet Messaging can be traced back to roots in the TELNET and FTP protocols in the ARPANET. Early message transfer consisted of text messages in US-ASCII, using TELNET NVT line ending conventions, sent using FTP commands. There were only limited capabilities for authentication, and none for encryption or digital signatures. Delivery instructions were conveyed as transport protocol arguments. RFC 561 [I1.RFC561] standardized the message format, separating content into a header and a body, with the header comprised of named fields conveying information from sender to recipient. Actual delivery remained controlled by command arguments separate from message content. Message content was not altered during transport. Special purpose messaging commands in FTP were obsoleted by separate messaging protocols, first MTP [I2.RFC772], [I3.RFC780], then SMTP [I4.RFC788], [I5.STD10], [I6.STD10], [I7.STD10], [I8.RFC2821]. Despite early identification of the desirability of keeping "envelope" information separate from the message header and body [I9.RFC724], SMTP introduced the addition of trace fields pertaining to transport, which were written onto the message content instead of being conveyed in command arguments or being placed in a separate location. Typical SMTP transport of the time involved direct connection from sender to recipient, resulting in limited expansion of the message content. However in some circumstances, and as the operation of SMTP has evolved, there are typically many lines added to the message header. This has resulted in burying the "wheat" of the originator message header fields in the "chaff" of transport-related markings. Further changes to the basic Internet Message Format to date [I10.RFC733], [I11.STD11], [I12.RFC2822] have focused on tightening and clarifying message header field syntax. Additional extensions have resulted in more fields being added to the message header, exacerbating the problem. In response to the problem, user agent implementors have elected to suppress presentation of all but a few message header fields. Unfortunately, many of the fields conveying user-to-user, end-to-end information have become innocent casualties in the extermination of presentation of undesirable cruft, at least in some implementations. Some extension fields specify syntax which is inconsistent in sometimes subtle ways with the user-oriented basic format fields [I13.Spec], complicating message parsers. Meanwhile, the practice of modifying message content in transit has rendered end-to-end digital signatures and other desirable features difficult to achieve. Specialized mechanisms, usually using MIME [I14.RFC2045], [I15.RFC2046], such as [I16.RFC1847] have addressed some specific issues, while the issue of clutter in presentation has remained largely unaddressed. Lilly Expires January 10, 2006 [Page 3] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 1.2. Other Directions As the U.S. ARPANET has transformed into the international Internet, there has been a desire for internationalization of text components of message content. MIME [I17.RFC2047], [I18.RFC2231], [I19.Errata] has again addressed some of these issues, but further internationalization has been limited by the need to maintain backward compatibility with the large installed base of software which transports and processes the Internet Message Format. User agents, the originator's as well as recipients', sometimes wish to record information or to advertise themselves. Message submission agents may wish to record authentication or other information pertaining to a message or its submission. List expanders often wish to provide information. Unfortunately, that compounds the obfuscation of user-to-user communication, and there is interaction between multiple list expansions. Gateways also typically [I20.RFC2156] record information in the message header. Message delivery agents (MDAs), filters such as Sieve [I21.RFC3028] implementations, and message stores may also wish to record information in the message header. 2. Goals The goals of specifying an extensible message format include: o Backward compatibility with existing transport and user agents o Separation of end-to-end, user-to-user communications from transport markings, advertisements, and other information, facilitating end-to-end security measures (signing and encryption) o Compartmentalization of different types of ancillary information and markings both to reduce confusion resulting from mixture of data and to simplify identificatio and handling of specific types of ancillary information o Extensibility to provide a migration path for enhanced internationalization, experiments with alternate message format syntax, etc., while maintaining a reliable, backward-compatible means of communications 3. Mechanism, Implementation Overview, and Notation The specification detailed in companion documents and outlined briefly below uses MIME [I14.RFC2045], [I15.RFC2046] media types and mechanisms as words and phrases to form a language for specifying an extensible message interchange format. Despite the acronym chosen for the format, its applicability is not limited to electronic mail; Lilly Expires January 10, 2006 [Page 4] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 just as the current Internet Message Format is used by applications such as voice mail, fax, data interchange, and news, those applications may choose to extend and use this format. The overall extensible format consists of a MIME multipart wrapper containing a multipart/alternative wrapper which in turn contains (at least in initial implementations) a MIME message/rfc822 content. There may be additional parts in the outer wrapper for holding information specific to different types of processors (list expanders, user agents, etc.). The inner multipart/alternative wrapper provides extensibility; as new message formats are devised, they may be included in addition to the backward-compatible message/rfc822 component. For brevity, discussion and illustration of the extensible message format will use an indented presentation with part numbering based on that specified in [I22.RFC3501]. A minimal instance would be shown as: multipart/email 0 multipart/alternative 1 message/rfc822 1.1 text/plain 1.1.1 close delimiter 1 close delimiter 0 4. Compatibility Because the format is a MIME message, it is compatible with existing transport mechanisms and with MIME-compatible message processors. Transport mechanisms like SMTP are free to scribble various and sundry things in the header of the outermost wrapper without invalidating any digital signature applied to the inner, end-to-end content, and without obfuscating the communications therein. Non-MIME recipient user agents will of course display the message as text, as is the case with any MIME message and such agents. At least the markings made by transport etc. will be separated from the user-to-user content. 5. Extensibility Roadmap As additional information separate from user content is identified for inclusion in the overall message, media types to contain that information can be defined and incorporated in the outer multipart wrapper's parts. Additional message formats can be defined for the user communications and incorporated in the inner multipart/alternative wrapper. Such formats might incorporate additional internationalization features and/or might use a more rigorous syntax, perhaps even self-describing header information. 6. Security Considerations No security considerations are addressed by this memo. Security considerations are addressed in companion documents. Lilly Expires January 10, 2006 [Page 5] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 7. Internationalization Considerations This memo raises no new internationalization considerations. It identifies some internationalization issues in general terms, and discusses an approach to those issues, also in general terms. Internationalization issues are discussed in detail in companion documents. 8. IANA Considerations This memo adds no new IANA considerations. 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. Informative References [I1.RFC561] Bhushan, A., Pogran, K., Tomlinson, R., and J. White, "Standardizing Network Mail Headers", RFC 561, September 1973. [I2.RFC772] Sluizer, S. and J. Postel, "Mail Transfer Protocol", RFC 772, September 1980. [I3.RFC780] Sluizer, S. and J. Postel, "Mail Transfer Protocol", RFC 780, May 1981. [I4.RFC788] Postel, J., "Simple Mail Transfer Protocol", RFC 788, November 1981. [I5.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. Lilly Expires January 10, 2006 [Page 6] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 [I6.STD10] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. [I7.STD10] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986. [I8.RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [I9.RFC724] Crocker, D., Pogran, K., Vittal, J., and D. Henderson, "Proposed official standard for the format of ARPA Network messages", RFC 724, May 1977. [I10.RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977. [I11.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [I12.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [I13.Spec] Lilly, B., "Implementer-friendly Specification of Message and MIME-Part Header Fields and Field Components" (draft-lilly-field-specification-04.txt), June 2005. [I14.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [I15.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [I16.RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [I17.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [I18.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [I19.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html Lilly Expires January 10, 2006 [Page 7] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 [I20.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. [I21.RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001. [I22.RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Author's Address Bruce Lilly Email: blilly@erols.com Full Copyright Statement Copyright (C) The Internet Society (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. Lilly Expires January 10, 2006 [Page 8] Internet-Draft EMAIL Part One: Introduction & Overview July 2005 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 10, 2006 [Page 9]