Internet DRAFT - draft-lilly-extensible-internet-message-format-p03
draft-lilly-extensible-internet-message-format-p03
Network Working Group B. Lilly
Internet-Draft July 2005
Intended status: Best Current Practice
Expires: January 11, 2006
Extensible Message Application Interchange Language (EMAIL) --
Part Three: Media Types Registration Guidelines
draft-lilly-extensible-internet-message-format-p03-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 supplementary guidelines for registration of media types
relevant to the extensible message format.
Lilly Expires January 11, 2006 [Page 1]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
Table of Contents
1. Introduction.................................................... 3
2. Tree............................................................ 3
3. Syntax.......................................................... 3
4. Semantics....................................................... 3
5. Encoding........................................................ 3
6. Number.......................................................... 3
7. Parameters...................................................... 4
7.1. Version.................................................... 4
7.2. Sequence................................................... 4
8. Interoperability................................................ 4
9. Specification of Internationalization........................... 5
10. Address Security Issues........................................ 5
11. An IANA Considerations Section is Mandatory.................... 5
12. Security Considerations........................................ 5
13. Internationalization Considerations............................ 5
14. IANA Considerations............................................ 5
Appendix A. Disclaimers............................................ 5
Normative References............................................... 6
Informative References............................................. 6
Author's Address................................................... 6
Lilly Expires January 11, 2006 [Page 2]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
1. Introduction
This memo will define guidelines for registration of media types
suitable for use with the extensible message format defined in
companion documents. Media type registrations will of course also
have to comply with the registration procedure(s) [N1.RFC2048],
[N2.MediaReg].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD",
"RECOMMENDED" and "MAY" in this document are to be interpreted as
described in [N3.BCP14].
2. Tree
Media types suitable for use in the extensible message format are
registered under the IETF standards tree "message" top-level type.
3. Syntax
The syntax of the media type should be specified clearly to
facilitate interoperable implementations. A message subtype has
characteristics defined in [N4.RFC2046]. If the subtype consists
solely of sets of fields, the applicable fields should be specified,
and there should be a clear indication that there is no non-field
content. Conversely, if there is provision for free-form text as
well as fields, that should be clearly indicated. Field syntax
should be clear and unambiguous, by reference to an external
specification and/or by provision of a precise specification in the
RFC containing the registration form. Refer to [I1.Spec] for some
additional guidelines for specification of fields.
4. Semantics
The semantics of each field specified for use in the media type
should be clearly specified [I1.Spec].
5. Encoding
Encoding of message subtypes is restricted to the identity encodings
7bit, 8bit, and binary. Message subtypes which can use 7bit encoding
have maximum compatibility and are recommended by [N4.RFC2046]. If
8bit or binary encoding is required, there should be a clear
statement to that effect both in the registration form data and in
the specification text.
6. Number
In some cases, multiple instances of a particular media type within
the enclosing multipart/email wrapper are sensible and permissible;
in other cases no more than a single instance is allowed. The
specification SHOULD be very clear on this matter.
Lilly Expires January 11, 2006 [Page 3]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
If a media type is to be considered mandatory in multipart/email,
that MUST be clearly specified and a new specification of
multipart/email (with a version change) is REQUIRED.
7. Parameters
7.1. Version
A required "version" parameter is RECOMMENDED. Such a parameter can
serve to distinguish versions of the media type which have
incompatible characteristics. It is further RECOMMENDED that the
version parameter be specified as an unsigned decimal integer number
represented in ASCII digits in order to avoid misinterpretation of
the value [I1.Spec].
7.1.1. Guidelines for Version Change
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 (e.g. some field)
o specification such that existence or content of some part affects
processing or display of the media type as a whole or of any part
other than the specific part whose existence or content is
concerned
o 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.
A media type definition suitable as an optional part within
multipart/email does not require a new version of multipart/email
unless the second item above applies.
7.2. Sequence
Where multiple instances of a particular media type may be sensible
in the extensible message format, a required "sequence" parameter is
also RECOMMENDED. Such a parameter, ideally having a one-based
unsigned decimal integer value expressed as ASCII digits can
facilitate ordering of such types within the enclosing
multipart/email wrapper by applications without the need to parse
each individual section and/or apply heuristics.
8. Interoperability
The registration form interoperability considerations section will
require some careful thought. Note that unrecognized message
subtypes will be treated as application/octet-stream by
MIME-conforming implementations.
Lilly Expires January 11, 2006 [Page 4]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
9. Specification of Internationalization
A media type which addresses internationalization issues SHOULD have
an Internationalization Considerations section as noted in
[I2.BCP18].
10. Address Security Issues
Security issues must be addressed in the specifying document and
registration form. A document MAY detail considerations in the form
and reference that text in a Security Considerations section or vice
versa.
11. An IANA Considerations Section is Mandatory
At minimum, a media type registration requires IANA action to
register the media type upon approval. If fields are specified,
entries may need to be made in a registry per [I3.BCP90]. If
keywords or assigned numbers are specified, a registry may need to be
amended or established. These issues MUST be discussed in an IANA
Considerations section in order to promote interoperability.
12. Security Considerations
This memo addresses best practice for registration of media types and
is believed to raise no security issues.
13. Internationalization Considerations
This memo addresses best practice for registration of media types.
Some media types may require 8bit or binary transport, which
conflicts with the [N4.RFC2046] recommendation for use of 7bit
encoding for message subtypes. The issue is discussed in section 5
of this memo.
14. IANA Considerations
This memo addresses best practice for registration of media types and
does not itself require any IANA action.
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.
Lilly Expires January 11, 2006 [Page 5]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
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.
Normative References
[N1.RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[N2.MediaReg] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures"
(draft-freed-media-type-reg-04.txt), April 2005.
[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.
Informative References
[I1.Spec] Lilly, B., "Implementer-friendly Specification of Message
and MIME-Part Header Fields and Field Components"
(draft-lilly-field-specification-04.txt), June 2005.
[I2.BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[I3.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
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.
Lilly Expires January 11, 2006 [Page 6]
Internet-Draft EMAIL Part 3: Media Registration Guidelines July 2005
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 7]
