Internet DRAFT - draft-lilly-extensible-internet-message-format-p04
draft-lilly-extensible-internet-message-format-p04
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 = <List-ID field per RFC 2919>
MIME-field = <MIME fields, except MIME-Version>
obs-ws = [FWS] ; FWS per RFC 2822, SHOULD parse, MUST
; NOT generate
URI = <URI per corresponding specification>
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]
