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]