Network Working Group G. Klyne Request for Comments: 3864 Nine by Nine BCP: 90 M. Nottingham Category: Best Current Practice BEA J. Mogul HP Labs September 2004 Registration Procedures for Message Header Fields Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Structure of this Document . . . . . . . . . . . . . . . 3 1.2. Document Terminology and Conventions . . . . . . . . . . 4 2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4 2.1. Permanent and Provisional Header Fields. . . . . . . . . 4 2.2. Definitions of Message Header Fields . . . . . . . . . . 5 2.2.1. Application-specific Message Header Fields. . . . 5 2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6 3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6 4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6 4.1. Header Field Specification . . . . . . . . . . . . . . . 7 4.2. Registration Templates . . . . . . . . . . . . . . . . . 7 4.2.1. Permanent Message Header Field Registration Template. . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Provisional Message Header Field Submission Template. . . . . . . . . . . . . . . . . . . . . 8 4.3. Submission of Registration . . . . . . . . . . . . . . . 10 4.4. Objections to Registration . . . . . . . . . . . . . . . 10 4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11 4.6. Comments on Header Definitions . . . . . . . . . . . . . 12 4.7. Location of Header Field Registry. . . . . . . . . . . . 12 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 30]. Benefits of a central registry for message header field names include: o providing a single point of reference for standardized and widely-used header field names; o providing a central point of discovery for established header fields, and easy location of their defining documents;
o discouraging multiple definitions of a header field name for different purposes; o helping those proposing new header fields discern established trends and conventions, and avoid names that might be confused with existing ones; o encouraging convergence of header field name usage across multiple applications and protocols. The primary specification for Internet message header fields in email is the Internet mail message format specification, RFC 2822 . HTTP/1.0  and HTTP/1.1  define message header fields (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. RFC 1036  defines message header elements for use with Netnews feeds. These specifications also define a number of header fields, and provide for extension through the use of new field-names. There are many other Internet standards track documents that define additional header fields for use within the same namespaces, notably MIME  and related specifications. Other Internet applications that use MIME, such as SIP (RFC 3261 ) may also use many of the same header fields (but note that IANA maintains a separate registry of header fields used with SIP). Although in principle each application defines its own set of valid header fields, exchange of messages between applications (e.g., mail to Netnews gateways), common use of MIME encapsulation, and the possibility of common processing for various message types (e.g., a common message archive and retrieval facility) makes it desirable to have a common point of reference for standardized and proposed header fields. Listing header fields together reduces the chance of an accidental collision, and helps implementers find relevant information. The message header field registries defined here serve that purpose. Section 2 discusses the purpose of this specification, and indicates some sources of information about defined message header fields. Section 4 defines the message header field name repositories, and sets out requirements and procedures for creating entries in them.
RFC 2119 . RFC 2434 , where the specification must be published in an RFC (standards-track, experimental, informational or historic), or as an "Open Standard" in the sense of RFC 2026, section 7 . o A Provisional Message Header Field Repository, intended for any header field proposed by any developer, without making any claim about its usefulness or the quality of its definition. The policy for recording these is "Private Use", per RFC 2434 . Neither repository tracks the syntax, semantics or type of field- values. Only the field-names, applicable protocols and status are registered; all other details are specified in the defining documents referenced by repository entries. Significant updates to such references (e.g., the replacement of a Proposed Standard RFC by a Draft Standard RFC, but not necessarily the revision of an Internet- draft) SHOULD be accompanied by updates to the corresponding repository entries.
RFC 2822  defines a general syntax for message headers, and also defines a number of fields for use with Internet mail. HTTP/1.0  and HTTP/1.1  do likewise for HTTP. Additional field names are defined in a variety of standards-track RFC documents, including: RFC 1036 , RFC 1496 , RFC 1505 , RFC 1864 , RFC 2156 , RFC 2183 , RFC 2045 , RFC 2046 , RFC 2557 , RFC 2227 , RFC 2231 , RFC 2298 , RFC 2369 , RFC 2421 , RFC 2518 , RFC 2617 , RFC 2821 , RFC 2912 , RFC 2919 , RFC 2965 , and RFC 3282 . 26] , NNTP newsgroup feeds , HTTP web access  and any other that uses MIME  encapsulation of message content. In some cases (notably HTTP ), the header syntax and usage is redefined for the specific application. This registration is concerned only with the allocation and specification of field names, and not with the details of header implementation in specific protocols. In some cases, the same field name may be specified differently (by different documents) for use with different application protocols; e.g., The Date: header field used with HTTP has a different syntax than the Date: used with Internet mail. In other cases, a field name may have a common specification across multiple protocols (ignoring protocol-specific lexical and character set conventions); e.g., this is generally the case for MIME header fields with names of the form 'Content-*'. Thus, we need to accommodate application-specific fields, while wishing to recognize and promote (where appropriate) commonality of other fields across multiple applications. Common repositories are used for all applications, and each registered header field specifies the application protocol for which the corresponding definition applies. A given field name may have multiple registry entries for different protocols; in the Permanent Message Header Field registry, a given header field name may be registered only once for any given protocol. (In some cases, the registration may reference several defining documents.)
Section 4.2) for all headers defined in the document in their IANA considerations section. Use of the header registry MAY be mandated by other protocol specifications, however, in the absence of such a mandate use of the registry is not required.
RFC 2026, section 7 . A registered field name SHOULD conform at least to the syntax defined by RFC 2822 , section 3.6.8. Further, the "." character is reserved to indicate a naming sub- structure and MUST NOT be included in any registered field name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document. Header field names may sometimes be used in URIs, URNs and/or XML. To comply with the syntactic constraints of these forms, it is recommended that characters in a registered field name are restricted to those that can be used without escaping in a URI  or URN , and that are also legal in XML  element names. Thus, for maximum flexibility, header field names SHOULD further be restricted to just letters, digits, hyphen ('-') and underscore ('_') characters, with the first character being a letter or underscore. RFC 2026, section 7 , and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol. The registration template has the following form. PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: Header field name: The name requested for the new header field. This MUST conform to the header field specification details noted in Section 4.1.
Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used. Status: Specify "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined. For non-IETF specifications, those formally approved by other standards bodies should be labelled as "standard"; others may be "informational" or "deprecated" depending on the reason for registration. Author/Change controller: For Internet standards-track, state "IETF". For other open standards, give the name of the publishing body (e.g., ANSI, ISO, ITU, W3C, etc.). For other specifications, give the name, email address, and organization name of the primary specification author. A postal address, home page URI, telephone and fax numbers may also be included. Specification document(s): Reference to document that specifies the header for use with the indicated protocol, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections MAY also be included, but is not required. Related information: Optionally, citations to additional documents containing further relevant information. (This part of the registry may also be used for IESG comments.) Where a primary specification refers to another document for substantial technical detail, the referenced document is usefully mentioned here.
The specification SHOULD indicate an email address for sending technical comments and discussion of the proposed message header. The submission template has the following form. PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE: Header field name: The name proposed for the new header field. This SHOULD conform to the field name specification details noted in Section 4.1. Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used. Status: Specify: "provisional". This will be updated if and when the header registration is subsequently moved to the permanent registry. Author/Change controller: The name, email address, and organization name of the submission author, who may authorize changes to or retraction of the repository entry. A postal address, home page URI, telephone and fax numbers may also be included. If the proposal comes from a standards body working group, give the name and home page URI of the working group, and an email address for discussion of or comments on the specification. Specification document(s): Reference to document that specifies the header for use with the indicated protocol. The document MUST be an RFC, a current Internet-draft or the URL of a publicly accessible document (so IANA can verify availability of the specification). An indication of the relevant sections MAY also be included, but is not required. NOTE: if the specification is available in printed form only, then an Internet draft containing full reference to the paper document should be published and cited in the registration template. The paper specification MAY be cited under related information. Related information: Optionally, citations to additional documents containing further relevant information.
33] . Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address . IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied. When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry. Section 4.1 and Section 4.2.2. Some reasonable grounds for refusal might be: o There is IETF consensus that publication is considered likely to harm the Internet technical infrastructure in some way. o Disreputable or frivolous use of the registration facilities. o The proposal is sufficiently lacking in purpose, or misleading about its purpose, that it can be held to be a waste of time and effort. o Conflict with some current IETF activity.
Note that objections or disagreements about technical detail are not, of themselves, considered grounds to refuse listing in the provisional repository. After all, one of its purposes is to allow developers to communicate with a view to combining their ideas, expertise and energy to the maximum benefit of the Internet community. Publication in an RFC or other form of Open Standard document (per RFC 2026 , section 7) is sufficient grounds for publication in the permanent registry. To assist IANA in determining whether or not there is a sustainable objection to any registration, IESG nominates a designated expert to liaise with IANA about new registrations. For the most part, the designated expert's role is to confirm to IANA that the registration criteria have been satisfied. The IESG or their designated expert MAY require any change or commentary to be attached to any registry entry. The IESG is the final arbiter of any objection. 33].) A change to a permanent message header field registration MAY be requested by the IESG. A change to or retraction of any Provisional Message Header Field Repository entry MAY be requested by the IESG or designated expert. IANA MAY remove any Provisional Message Header Field Repository entry whose corresponding specification document is no longer available (e.g., expired Internet-draft, or URL not resolvable). Anyone may notify IANA of any such cases by sending an email to the designated email address . Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document (consistent with the requirements of section Section 4.2.2) is available.
It is intended that entries in the Permanent Message Header Field Registry may be used in the construction of URNs (per RFC 2141 ) which have particular requirements for uniqueness and persistence (per RFC 1737 ). Therefore, once an entry is made in the Permanent Message Header Registry, the combination of the header name and applicable protocol MUST NOT subsequently be registered for any other purpose. (This is not to preclude revision of the applicable specification(s) within the appropriate IETF Consensus rules, and corresponding updates to the specification citation in the header registration.) 33]. http://www.iana.org/assignments/message-headers/ message-header-index.html Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.1. o A new IANA repository listing provisional message header fields per Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.2. o IESG appoints a designated expert to advise IANA whether registration criteria for proposed registrations have been satisfied. No initial registry entries are provided.
 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.  Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.  Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages", RFC 1496, August 1993.  Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, August 1993.  Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.  Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.  Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
 Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.  Moats, R., "URN Syntax", RFC 2141, May 1997.  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.  Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, August 1997.  Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.  Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.  Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.  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.  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.  Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.  Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.  Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.  Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.  Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.  Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.  "Mail address for announcement of new header field submissions", Mail address: email@example.com  "Mail address for subscription to ietf-message- firstname.lastname@example.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO THE MAILING LIST ITSELF)", Mail address: ietf-message-headers- email@example.com  "Mail address for submission of new header field templates", Mail address: firstname.lastname@example.org
http://www.ninebynine.net/ Mark Nottingham BEA Systems 235 Montgomery St. Level 15 San Francisco, CA 94104 USA EMail: email@example.com Jeffrey C. Mogul HP Labs 1501 Page Mill Road Palo Alto, CA 94304 US EMail: JeffMogul@acm.org
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 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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.