Internet DRAFT - draft-lilly-extensible-internet-message-format-p01
draft-lilly-extensible-internet-message-format-p01
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]
