Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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.

This Internet-Draft will expire on July 23, 2002.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

This specification defines registration procedures for the message headers used by Internet mail, HTTP, news and other applications.

Discussion of this document

Please send comments to <ietf-822@imc.org>. To subscribe to this list, send a message with the body 'subscribe' to <ietf-822-request@imc.org>.

Table of Contents

1.  Introduction
1.1  Structure of this document
1.2  Document terminology and conventions
2.  Message headers
2.1  Standard and non-standard headers
2.2  Definitions of message headers
2.2.1  Application-specific message headers
3.  Registration procedure
3.1  Header specification
3.2  Registration templates
3.2.1  Normative header template
3.2.2  Provisional header template
3.3  Submission of registration
3.4  Change control
3.5  Comments on header definitions
3.6  Location of message header registry
4.  IANA considerations
5.  Security considerations
6.  Acknowledgements
§  References
§  Authors' Addresses
A.  Revision history
A.1  draft-klyne-msghdr-registry-02
A.2  draft-klyne-msghdr-registry-01
A.3  draft-klyne-msghdr-registry-00
B.  Todo
§  Full Copyright Statement

1. Introduction

This specification defines registration procedures for the message headers used by Internet mail, HTTP, newsgroup feeds and other Internet applications.

Benefits of a central registry for message headers include:

• to provide a single point of reference for standardized headers;
• to provide a central point of discovery for established headers, and easy location of their defining documents;
• to discourage multiple definitions of a header name for different purposes;
• to help those proposing new headers discern established trends and conventions, and avoid names that might be confused with existing ones;
• to encourage convergence of header name usage across multiple applications/protocols.

The primary specification for Internet message headers in email is the Internet mail message format specification, RFC 2822 [34]. HTTP/1.0[7] and HTTP/1.1[28] define message headers (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. These specifications also define a number of headers, and and provide for extension through the use of new field-names.

There are many other Internet standards track documents that define additional headers for use within the same namespaces, notably MIME[8] and related specifications. Other Internet applications that use MIME, such as newsgroup feeds (RFC 1036 [1]) may also use many of the same headers.

Although in principle each application defines its own set of valid headers, exchange of messages between applications (e.g. mail to news 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 single point of reference for standardized and proposed headers. The message header registries defined here serve that purpose.

1.1 Structure of this document

Section Message headers discusses the purpose of this specification, and indicates some sources of information about defined message headers.

Section Registration procedure defines the message header registry, and sets out requirements and procedures for creating entries in it.

1.2 Document terminology and conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [14].

NOTE: indented comments like this provide additional nonessential information about the rationale behind this document.

[[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]]

2. Message headers

2.1 Standard and non-standard headers

Many message headers are defined in standards-track documents, which means they have been subjected to a process of community review and achieved consensus that they provide a useful and well-founded capability. Many other headers have been defined and adopted for private use; some of these have found widespread use.

The registries defined here are intended to cater for all of these headers, while maintaining a clear distinction and status for those which have community consensus. To this end, two registries are defined:

• Normative Message Headers, intended for headers defined in IETF standards-track documents, or those that have achieved a comparable level of community review. The assignment policy for such registration is "IETF Consensus", as defined by RFC 2434 [26].
• Provisional Message Headers, intended for any header proposed by any developer, without making any claim about the usefulness quality of its definition. The assignment policy for registration of these is "Private Use", per RFC 2434 [26].

Neither registry tracks the syntax, semantics or type of field-values. Only the field-names are registered; all other details are specified in the defining documents referenced by registry entries. Significant updates to such references (e.g., the replacement of a Draft Standard RFC by a Proposed Standard RFC, but not the revision of an Internet-Draft) SHOULD be accompanied by updates to the corresponding registry entries.

Note that there exist at least two other sources information about message headers:

• RFC 2076 [11], as updated [40], contains a list of commonly used message headers, and
• Dan Bernstein maintains a list of standard and non-standard mail message headers [41].

2.2 Definitions of message headers

RFC 2822[34] defines a general syntax for message headers, and also defines a number of headers for use with Internet mail. HTTP/1.0[7] and HTTP/1.1[28] do likewise for HTTP. Additional header names are defined in a variety of standards-track RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3], RFC 1766 [5], RFC 1864 [6], RFC 2156 [16], RFC 2183 [17], RFC 2045 [8], RFC 2046 [8], RFC 2109 [12] (obsoleted by RFC 2965), RFC 2110 [13], RFC 2227 [18], RFC 2298 [20], RFC 2369 [23], RFC 2421 [25], RFC 2518 [27], RFC 2617 [29], RFC 2821 [33], RFC 2912 [36], RFC 2919 [37], and RFC 2965 [38].

2.2.1 Application-specific message headers

Internet applications that use message headers include Internet mail [33][34], NNTP newsgroup feeds [1], HTTP web access [28] and any other that uses MIME [8] encapsulation of message content.

In some cases (notably HTTP [28]), the header syntax and usage is redefined for the specific application. This registration is concerned only with the allocation and specification of header names, and not with the details of header implementation in specific protocols.

In some cases, the same header name may be specified differently (by different documents) for use with different application protocols; e.g. The Date: header used with HTTP has a different syntax than the Date: header used with Internet mail. In other cases, a header 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 headers with names of the form 'Content-*'.

Thus, we need to accommodate application-specific headers, while wishing to recognize and promote (where appropriate) commonality of other headers across multiple applications. Common registries are used for all applications, and each registered header specifies the application protocol for which the registered definition applies. A given header name may have multiple registry entries for different protocols; in the Normative Message Headers registry, a given header name may be registered only once for any given protocol.

3. Registration procedure

The procedure for registering a message header is:

1. Construct a header specification
2. Prepare a registration template
3. Submit the registration template

3.1 Header specification

Registration of a new message header starts with construction of a proposal that describes the syntax, semantics and intended use of the header. For normative headers, this proposal MUST be published as an RFC.

A registered header name MUST conform at least to the syntax defined by RFC 2822, section 3.6.8, for "field name".

Further, the "." character is reserved to indicate a naming sub-structure and MUST NOT be included in any registered header name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document.

It is further RECOMMENDED that characters in a registered message header name are restricted to those characters that can be used without escaping in a URI [24] or URN [15], namely upper- or lower-case ASCII letters, decimal digits, "(", ")", "+", ",", "-", "=", "@", ";", "$", "_", "!", "*" and "'". Of course, a header name must also conform to any applicable rules of the protocol(s) with which it is used. Many headers names may find some use in conjunction with XML[39], in which case the name characters should be further restricted to just letters, digits, hyphen ('-') and underscore ('_') characters, with the first character being a letter or underscore.

3.2 Registration templates

The registration template for a message header may be contained in the defining document, or prepared separately.

3.2.1 Normative header template

An header registered as a Normative Message Header MUST be defined according to "IETF Consensus" rules (per RFC 2434 [26]), and MUST have a name which is unique among all the Normative Message Headers that may be used with the same application protocol. The header name MUST NOT start with "X-" or "x-".

The registration template has the following form.

NORMATIVE HEADER REGISTRATION TEMPLATE:

Header name:

The name requested for the new header. This MUST conform to the header specification details above.

Applicable protocol:

Specify "mail", "http", "news", or cite any other standards-track RFC defining the protocol with which the header is intended to be used.

Specification document(s):

Reference to the RFC(s) that specify the header for use with the indicated protocol. 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.

3.2.2 Provisional header template

Registration as a Provisional Message Header does not imply any kind of endorsement by the IETF, IANA or any other body.

The only requirement for a header to be registered as a Provisional Message Header is that it MUST have a citable specification.

The registration template has the following form.

PROVISIONAL HEADER REGISTRATION TEMPLATE:

Header name:

The name requested for the new header. This SHOULD conform to the header specification details above.

Applicable protocol:

Specify "mail", "http", "news", or cite any other standards-track RFC defining the protocol with which the header is intended to be used.

Specification document(s):

Reference to document(s) that specifies the header for use with the indicated protocol. 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.

Author/Change controller:

The name and email address of the author, and person who may authorize changes to or retraction of the registration.

3.3 Submission of registration

The registration is submitted for incorporation in the IANA message header registry by one of the following means:

• An IANA considerations section in a defining RFC, calling for registration of the message header and referencing the registration template within the same document. Registration of the header is processed as part of the RFC publication process.
• Sending the registration template in an email to the designated email address [45]. IANA will register the message header if the requested name and the specification document meet the criteria stated.

3.4 Change control

Change control of a header registration is subject to the same condition as the initial registration; i.e. publication of an IESG-approved RFC for a Normative Message Header, or on request of the indicated author/change controller for a Provisional Message Header.

In addition, a change to or retraction of Provisional Message Header registration may be requested by the IESG.

It is intended that entries in the Normative Header Registry may be used in the construction of URNs (per RFC 2141 [15]) which have particular requirements for uniqueness and persistence (per RFC 1737 [4]). Therefore, once an entry is made in the Normative Message Header registry, the combination of the header name and applicable protcol 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.)

3.5 Comments on header definitions

[[[Review this]]]

Comments on proposed message headers should preferably be sent to the discusion forum for the protocol specification concerned. They may also be sent to the IETF-822 list [45] if they concern wider implications than are addressed by the protocol header specification document.

3.6 Location of message header registry

The message header registry is accessible from IANA's web site [46].

4. IANA considerations

This specification calls for:

• A new IANA registry for normative message headers per section Registration procedure of this document. The policy for inclusion in this registry is described in sections Header specification and Normative header template.
• A new IANA registry for provisional message headers per section Registration procedure of this document. The policy for inclusion in this registry is described in sections Header specification and Provisional header template.

Initial header registrations are provided by the following companion documents:

• For mail message headers: Registration of mail header fields[42]
• For HTTP message headers: Registration of HTTP header fields[43]

5. Security considerations

No security considerations are introduced by this specification beyond those already inherent in the use of message headers.

6. Acknowledgements

The authors would like to thank Anja Feldmann for "Usage of HTTP header fields"[44] and the http-wg mailing list members for their input.

The authors also gratefully acknowledge the contribution of those who reviewed earlier versions of this memo: Charles Lindsey, [[[...]]]

References

Authors' Addresses

Appendix A. Revision history

[[[Please remove this section on final publication]]]

A.1 draft-klyne-msghdr-registry-02

02a 22-Jan-2002:

• Merged with HTTP header registry proposal.
• Move initial registrations to separate documents.

A.2 draft-klyne-msghdr-registry-01

01a 04-Jan-2002:

• In response to feedback from interested parties, expanded the registry to cover Normative and Provisional message header registrations.
• Defined a formal role for the applicable protocol(s) in the registry: the combination of header name and any applicable protocol must be unique for a Normative Message Header.
• Noted further constraints to the header name format for XML name compatibility.
• Fixed registration policy for a Normative Message Header to be "IETF Consensus".

A.3 draft-klyne-msghdr-registry-00

00a 27-Sep-2001:

• Document initially created.

Appendix B. Todo

[[[Please remove this section on final publication]]]

• Finalize references to initial registrations.
• Finalize email address for submission of registration templates.
• Finalize web address for registry.
• Confirm that IANA are comfortable with the proposed procedures. In particular the uniqueness requirements on registry entries.
• Consider the following comment about X-headers: we may need to do that protocol-by-protocol; IIRC their status is different in HTTP than in mail, for example. In the case of HTTP, I don't think X- headers should be encouraged; however, I can see documenting current X- headers. The trick is distinguishing between current and new. If we don't take X-headers, it sends the message that they shouldn't be used because you can't check the status of them.
• Consider whether provisions to prevent abuse are OK. Currently, IESG can override any registration. One alternative proposed was to have IESG-appointed domain expert review of all registrations.
• Should the controller of a registration always be the author of the corresponding specification.
• Confirm this is OK: no change controller is specified for normative headers because these are effectively under control of IESG, by virtue of being specified by an IESG-approved RFC.

Full Copyright Statement

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.