Network Working Group B. Lilly Internet Draft January 2005 Expires: July 14, 2005 Implementer-friendly Specification of Message and MIME-Part Header Fields and Field Components draft-lilly-field-specification-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667 [BCP78]. By submitting this Internet-Draft, the author represents that any applicable patent or other IPR claims of which he is aware have been or will be disclosed, and any of which he become aware will be disclosed, in accordance with RFC 3668. 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 . The list of Internet-Draft Shadow Directories can be accessed at . Copyright Notice Copyright(C)The Internet Society (2005). Abstract Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. 1. Introduction Internet messages consist of a message header and a body [STD11], [RFC2822]. MIME content begins with a MIME-part header [RFC2045], [RFC2046]. Message headers and MIME-part headers consist of fields. While the Message Format and MIME specifications define their respective overall formats and some specific fields, they also have provision for extension fields. A number of extension fields have been specified, some more or less completely than others. Incomplete or imprecise specification has led to interoperability problems as Lilly Expires July 14, 2005 [Page 1] Internet Draft Specification of Header Fields January 2005 implementers make assumptions in the absence of specifications. This memo identifies items of potential interest to implementers and section 4 of this memo may serve as a checklist for specifications of extension fields and field components. 2. Requirement Levels The key words "SHOULD", and "SHOULD NOT", in this document are to be interpreted as described in [BCP14]. 3. Scope This memo is intended to supplement various specifications, guidelines, and procedures for specification of header fields [STD11], [BCP9], [RFC2045], [RFC2046], [RFC2822], [BCP90]. It does not absolve authors of header field specifications from compliance with any provisions of those or other specifications, guidelines, and procedures. It offers clarification and supplementary suggestions that will promote interoperability and may spare specification authors many questions regarding incomplete header field specifications. 4. Specification Items 4.1. Established Conventions A number of conventions exist for naming and specifying header fields. It would be unwise to specify a field which conflicts with those conventions. 4.1.1. Naming Conventions Several conventions have been established for naming of header fields. 4.1.1.1. Resent- prefix Field names beginning with "Resent-" have particular semantics as given in [STD11] and [RFC2822]. If a Resent- version of a field is applicable, an author SHOULD say so explicitly, and SHOULD provide a comprehensive specification of any differences between the plain field and the Resent- version. 4.1.1.2. Content- prefix Field names beginning with "Content-" are MIME extension fields [RFC2045]. This prefix SHOULD be used for all MIME extension fields and SHOULD NOT be used for fields which are not MIME extension fields. 4.2. Common Specification Items Several items are specified for standard header fields; these items should also be specified for extension fields. Lilly Expires July 14, 2005 [Page 2] Internet Draft Specification of Header Fields January 2005 4.2.1. ABNF [STD11] is vague about where whitespace is permitted or required in header field syntax. [RFC2822] addresses that issue by defining grammar productions such as FWS and CFWS. Extension field ABNF SHOULD clearly specify where comments, line folding, and whitespace are prohibited and permitted, and SHOULD use the RFC 2822 grammar productions in ABNF for that purpose. All ABNF should be carefully checked for ambiguities and to ensure that all productions resolve to some combination of terminal productions provided by a normative reference. [RFC2234] provides several productions that may be useful. While use of suitable productions defined and in use is encouraged, specification authors are cautioned that some such productions have been amended by subsequently issued RFCs and/or by formal errata [Errata]. It is sometimes necessary or desirable to define keywords as protocol elements in structured fields. Protocol elements SHOULD be case-insensitive per the Internet Architecture [RFC1958]. Keywords are typically registered by IANA; a specification using registered keywords SHOULD include an IANA considerations section, and SHOULD indicate to readers of the specification precisely where IANA has set up the registry (authors will need to coordinate this with IANA prior to publication as an RFC). In many cases, it will be desirable to make provision for extending the set of keywords; that may be done by specifying that the set may be extended by publication of an RFC, or a formal review and registration procedure may be specified (typically as a BCP RFC). Provision may be made for experimental or private-use keywords. These typically begin with a case-insensitive "x-" prefix. Note that [BCP82] has specific considerations for use of experimental keywords. If some field content is to be considered human-readable text, there should be provision for specifying language in accordance with [BCP18]. Header fields typically use the mechanism specified in [RFC2047] as amended by [RFC2231] and [Errata] for that purpose. Note, however, that that mechanism applies only to three specific cases; unstructured fields, an RFC 822 "word" in an RFC 822 "phrase", and comments in structured fields. Any internationalization considerations should be detailed in an Internationalization Considerations section of the specification as specified in [BCP18]. 4.2.2. Minimum and Maximum Instances per Header Some fields are mandatory, others are optional. It may make sense to permit multiple instances of a field in a given header; in other cases at most a single instance is sensible. RFC 2822 specifies a minimum and maximum count per header for each standard field in a message; specification authors SHOULD likewise specify minimum and maximum counts for extension fields. Lilly Expires July 14, 2005 [Page 3] Internet Draft Specification of Header Fields January 2005 4.2.3. Categorization RFC 2822 defines categories of header fields (e.g. trace fields, address fields). Such categories have implications for processing and handling of fields. A specification author SHOULD indicate any applicable categories. 4.3. Semantics In addition to specifying syntax of a field, a specification document should indicate the semantics of each field. Such semantics are comprised of several aspects: 4.3.1. Producers, Modifiers, and Consumers Some fields are intended for end-to-end communication between author or sender and recipient; such fields should not be generated or altered by intermediaries in the transmission chain [Crocker04]. Other fields comprise trace information which is added during transport. Authors SHOULD clearly specify who may generate a field, who may modify it in transit, who should interpret such a field, and who is prohibited from interpreting or modifying the field. 4.3.2. What's it All About? When introducing a new field or modifying an existing field, an author should present a clear description of what problem or situation is being addressed by the extension or change. 4.3.3. Context The permitted types of headers in which the field may appear should be specified. Some fields might only be appropriate in a message header, some might appear in MIME-part headers as well as message headers, still others might appear in specialized MIME media types. 4.4. Overall Considerations Several factors should be considered regarding how a field interacts with the Internet at large, with the applications for which it is intended, and in interacting with other applications. 4.4.1. Security Every specification is supposed to include a carefully-considered Security Considerations section [RFC2223]. 4.4.2. Backwards Compatibility There is a large deployed base of applications which use header fields. Implementations that comprise that deployed base may change very slowly. It is therefore critically important to consider the impact of a new or revised field or field component on that deployed base. A new field, or extensions to the syntax of an existing field Lilly Expires July 14, 2005 [Page 4] Internet Draft Specification of Header Fields January 2005 or field component, might not be recognizable to deployed implementations. Depending on the care with which the authors of an extension have considered such backwards compatibility, such an extension might, for example: a. Cause a deployed implementation to simply ignore the field in its entirety. That is not a problem provided that it is a new field and that there is no assumption that such deployed implementations will do otherwise. b. Cause a deployed implementation to behave differently from how it would behave in the absence of the proposed change, in ways that are not intended by the proposal. That is a failure of the proposal to remain backwards compatible with the deployed base of implementations. There are many subtleties and variations that may come into play. Authors SHOULD very carefully consider backwards compatibility when devising extensions, and SHOULD clearly describe all known compatibility issues. 4.4.3. Compatibility With Legacy Content Content is sometimes archived for various reasons. It is sometimes necessary or desirable to access archived content, with the semantics of that archived content unchanged. It is therefore important that lack of presence of an extension field or field component should not be construed (by an extension specification) as conferring new semantics on a message or piece of MIME content which lacks that field or field component. 4.4.4. Interaction With Established Mechanisms Header fields are handled specially by gateways under various circumstances. Message fragmentation and reassembly [RFC2046] is one example. If special treatment is required for a header field under such circumstances, it SHOULD be clearly specified by the author of the specification. [RFC3798] is an example of how this might be handled (however, because that specification requires deployed RFC 2046-conforming implementations to be modified, it is not strictly backwards compatible). 5. Acknowledgments The author would like to acknowledge the helpful comments provided by members of the ietf-822 mailing list. In particular, Peter Koch and Keith Moore have made useful comments. 6. Security Considerations No new security considerations are addressed by this memo. The memo reinforces the need for careful consideration of security issues. Lilly Expires July 14, 2005 [Page 5] Internet Draft Specification of Header Fields January 2005 7. Internationalization Considerations This memo does not directly have internationalization considerations, however it reminds specification authors of the need to consider internationalization of textual field components. 8. IANA Considerations While no specific action is required of IANA in regard to this memo, it does note that some coordination between IANA and specification authors who do require IANA to set up registries is at least desirable, if not a necessity. IANA should also closely coordinate with the RFC Editor so that registries are set up and properly referenced at the time of publication of an RFC which refers to such a registry. IANA is also encouraged to work closely with authors and the RFC Editor to ensure that descriptions of registries maintained by IANA are accurate and meaningful. Normative References [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Lilly Expires July 14, 2005 [Page 6] Internet Draft Specification of Header Fields January 2005 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. Informative References [BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [Crocker04] Crocker, D., "Internet Mail Architecture", Work in progress [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. Author's Address Bruce Lilly Email: blilly(_at_)erols(_dot_)com Full Copyright Statement Copyright(C)The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 [BCP78], and except as set forth therein, the author retains all his rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE 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 [BCP78] and BCP 79 [BCP79]. Lilly Expires July 14, 2005 [Page 7] Internet Draft Specification of Header Fields January 2005 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(_at_)ietf(_dot_)org(_dot_) Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lilly Expires July 14, 2005 [Page 8]