TOC 
Network Working GroupG. Klyne
Internet-DraftNine by Nine
Expires: July 9, 2003M. Nottingham
 BEA
 J. Mogul
 Compaq WRL
 January 8, 2003

Registration procedures for message header fields
draft-klyne-msghdr-registry-06

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 9, 2003.

Copyright Notice

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

Abstract

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.

Discussion of this document

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



 TOC 

Table of Contents




 TOC 

1. Introduction

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

Benefits of a central registry for message header field names include:

The primary specification for Internet message header fields in email is the Internet mail message format specification, RFC 2822 [4]. HTTP/1.0[11] and HTTP/1.1[30] define message header fields (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. RFC 1036[5] 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[12] and related specifications. Other Internet applications that use MIME, such as SIP (RFC 2543 [29]) may also use many of the same header fields.

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 single 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.

1.1 Structure of this document

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

Registration procedure defines the message header field name repositories, and sets out requirements and procedures for creating entries in them.

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 [2].

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.]]]



 TOC 

2. Message header fields

2.1 Permanent and provisional header fields

Many message header fields 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, or represent a widespread use of which developers should be aware. Some are defined for experimental use, typically indicating consensus regarding their purpose but not necessarily concerning their technical details. Many others have been defined and adopted ad-hoc to address a locally occurring requirement; some of these have found widespread use.

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

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.

2.2 Definitions of message header fields

RFC 2822[4] defines a general syntax for message headers, and also defines a number of fields for use with Internet mail. HTTP/1.0[11] and HTTP/1.1[30] do likewise for HTTP. Additional field names are defined in a variety of standards-track RFC documents, including: RFC 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1766 [9], RFC 1864 [10], RFC 2156 [18], RFC 2183 [19], RFC 2045 [12], RFC 2046 [12], RFC 2109 [15] (obsoleted by RFC 2965), RFC 2110 [16], RFC 2227 [20], RFC 2298 [22], RFC 2369 [25], RFC 2421 [27], RFC 2518 [28], RFC 2617 [31], RFC 2821 [35], RFC 2912 [37], RFC 2919 [38], and RFC 2965 [39].

2.2.1 Application-specific message header fields

Internet applications that use similar message headers include Internet mail [35][4], NNTP newsgroup feeds [5], HTTP web access [30] and any other that uses MIME [12] encapsulation of message content.

In some cases (notably HTTP [30]), 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.)

2.2.2 MIME header fields

Some header fields with names of the form Content-* are associated with the MIME data object encapsulation and labelling framework. These header fields can meaningfully be applied to a data object separately from the protocol used to carry it.

MIME is used with email messages and other protocols that specify a MIME-based data object format. MIME header fields used with such protocols are defined in the registry with the protocol "mime", and as such are presumed to be usable in conjunction with any protocol that conveys MIME objects.

Other protocols do not convey MIME objects, but define a number of header fields with similar names and functions to MIME. Notably, HTTP defines a number of entity header fields that serve a purpose in HTTP similar to MIME header fields in email. Some of these header fields have the same names and similar functions to their MIME counterparts (though there are some variations). Such header fields must be registered separately for any non-MIME-carrying protocol with which they may be used.

It is poor practice to reuse a header field name from another protocol simply because the fields have similar (even "very similar") meanings. Protocols should share header field names only when their meanings are identical in all foreseeable circumstances. In particular, new header field names of the form Content-* should not be defined for non-MIME-carrying protocols unless their specification is exactly the same as in MIME.



 TOC 

3. Registration procedure

The procedure for registering a message header field is:

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

3.1 Header field specification

Registration of a new message header field starts with construction of a proposal that describes the syntax, semantics and intended use of the field. For entries in the Permanent Message Header Field Registry, this proposal MUST be published as an RFC, or as an Open Standard in the sense described by RFC 2026, section 7 [1].

A registered field name SHOULD conform at least to the syntax defined by RFC 2822 [4], 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 [26] or URN [17], and that are also legal in XML[40] 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.

3.2 Registration templates

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

3.2.1 Permanent message header field registration template

An header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], 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 Header field specification.
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC2045), "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.

3.2.2 Provisional message header field submission template

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

The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the permanent header field registry.

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 Header field specification.
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.

3.3 Submission of registration

The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods:

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.

3.4 Objections to registration

Listing of an entry in the provisional repository should not be lightly refused. An entry MAY be refused if there is some credible reason to believe that such registration will be harmful. In the absence of such objection, IANA SHOULD allow any registration that meets the criteria set out in Header field specification and Provisional message header field submission template. Some reasonable grounds for refusal might be:

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 IESG-approved RFC or other form of Open Standard document (per RFC 2026 [1], 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.

3.5 Change control

Change control of a header field registration is subject to the same condition as the initial registration; i.e. publication (or reclassification) of an Open Standards specification for a Permanent Message Header Field, or on request of the indicated author/change controller for a Provisional Message Header (like the original submission, subject to review on the designated email discussion list [44].)

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 [46]. 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 Provisional message header field submission template) 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 [17]) which have particular requirements for uniqueness and persistence (per RFC 1737 [8]). 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.)

3.6 Comments on header definitions

Comments on proposed registrations should be sent to the designated email discussion list [44].

3.7 Location of header field registry

The message header field registry is accessible from IANA's web site http://[[[IANA registry URL here]]].



 TOC 

4. IANA considerations

This specification calls for:

Initial header registrations are provided by the following companion documents:

No initial entries are provided for the provisional registry.



 TOC 

5. Security considerations

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



 TOC 

6. Acknowledgements

The shape of the registries described here owes much to energetic discussion of previous versions by many denizens of the IETF-822 mailing list.

The authors also gratefully acknowledge the contribution of those who provided valuable feedback on earlier versions of this memo: Charles Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle Cotton.



 TOC 

Normative References

[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.


 TOC 

Informative References

[5] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[6] 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.
[7] Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, August 1993.
[8] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[9] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[10] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[11] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[14] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[15] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997 (TXT, HTML, XML).
[16] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997 (TXT, HTML, XML).
[17] Moats, R., "URN Syntax", RFC 2141, May 1997 (TXT, HTML, XML).
[18] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[19] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997 (TXT, HTML, XML).
[20] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[21] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998 (TXT, HTML, XML).
[22] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998 (TXT, HTML, XML).
[23] Holtman, K., "The Safe Response Header Field", RFC 2310, April 1998 (TXT, HTML, XML).
[24] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998 (TXT, HTML, XML).
[25] 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 (TXT, HTML, XML).
[26] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998 (TXT, HTML, XML).
[27] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998 (TXT, HTML, XML).
[28] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999 (TXT, HTML, XML).
[29] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[30] 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 (TXT, PS, PDF).
[31] 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.
[32] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[33] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[34] Nielsen, H., Leach, P. and S. Lawrence, "An HTTP Extension Framework", RFC 2774, February 2000.
[35] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[36] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[37] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[38] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[39] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[40] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000.
[41] Palme, J., "Common Internet Message Header Fields", Internet draft draft-palme-mailext-headers-08, September 2002.
[42] Klyne, G., "Registration of mail header fields", Internet draft draft-klyne-hdrreg-mail-01, Jun 2002.
[43] Nottingham, M. and J. Mogul, "Registration of HTTP header fields", Internet draft [[[draft-nottingham-hdrreg-http-00]]], Jan 2002.
[44] "Mail address for announcement of new header field submissions", Mail address mailto:[[[ietf-message-headers]]]@ietf.org.
[45] "Mail address for subscription to [[[ietf-message-headers]]]@ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO THE MAILING LIST ITSELF)", Mail address mailto:[[[ietf-message-headers-request]]]@ietf.org.
[46] "Mail address for submission of new header field templates", Mail address mailto:[[[iana-message-headers]]]@iana.org.


 TOC 

Authors' Addresses

  Graham Klyne
  Nine by Nine
  14 Chambrai Close
  Appleford
  Abingdon, Oxon OX14 4NT
  UK
EMail:  GK-IETF@ninebynine.org
URI:  http://www.ninebynine.net/
  
  Mark Nottingham
  BEA Systems
  235 Montgomery St.
  Level 15
  San Francisco, CA 94104
  USA
EMail:  mnot@pobox.com
  
  Jeffrey C. Mogul
  Western Research Laboratory, Compaq Computer Corporation
  250 University Avenue
  Palo Alto, CA 94305
  US
Phone:  1 650 617 3304 (email preferred)
EMail:  JeffMogul@acm.org


 TOC 

Appendix A. Revision history

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

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

06a 05-Aug-2002:
  • Fixed typo.

06b 08-Jan-2003:
  • Response to last-call comments:
  • Updated author details.
  • Added section on MIME header fields, noting that MIME is treated as a separate protocol for registration purposes.
  • Separated normative references from informational references. (Some protocols mentioned as motivation for an aspect of this specification are cited as informational, on the basis that their specification is not needed for validation of a proposed registry entry.)
  • Added "mime" as an option under applicable protocols.
  • Moved URL of IANA registry from references section to body of document.
  • Added requirement that IESG's designated expert should confirm to IANA that registration criteria have been satisfied.
  • Noted appointment of IESG-designated expert in IANA considerations section.
  • Added temporary note to IANA considerations section that there are IANA-controlled email addresses and URLs yet to be allocated.
  • Widened options for status of a header field.
  • Revised some references.

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

05a 10-Jun-2002:
  • Updated contact details.
  • Updated reference to mail header field registration document.

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

04a 25-Mar-2002:
  • Added note about referencing paper-only specification documents.
  • Change 'news' -> 'netnews'.
  • Experimental standards don't cite IETF as change controller.
  • Added note that provisional registry entries SHOULD indicate a discussion list.
  • Clarify that a single registry may reference several specification documents.
  • Add "deprecated" to list of possible status values for permanent registry.
  • Conflict with IETF work noted as possible objection to listing in the provisional registry.
  • Several small editorial changes.

04b 25-Mar-2002:
  • Simplify the text describing recommended character limitations for header field names.
  • Re-arrange the text dealing with status for permanent registry entries.
  • More small editorial changes.

A.4 draft-klyne-msghdr-registry-03

03a 11-Feb-2002:
  • Re-organized repositories into Permanent and Provisional, names chosen with a view to reducing any spurious impression of legitimacy.
  • All entries have a status indicator. For provisional entries, this clearly indicates the non-settled nature of the entry.
  • Make provision for prior email notification to interested parties of submissions not published in an RFC.
  • Make limited provision for refusal or removal of harmful submissions. IESG may appoint a designated expert to assist IANA with any assessments needed.
  • Make provision for IANA to remove provisional entries whose specification is no longer available.
  • Proposed mailing list for announcement/discussion of new registrations, and another for notifying IANA.
  • Removed any reference to header names beginning with 'X-', on the basis that this is a protocol-specific convention.
  • Updated terminology to use "header field" more consistently, rather than just "header".
  • Revised permanent and provisional submission templates to have the same form and structure.

03b 11-Feb-2002:
  • Editorial fixes.

03c 19-Feb-2002:
  • Extend range of specifications acceptable for permanent registry entries to include "Open standards" (per RFC 2026).
  • Trim references to other informational lists of header information.
  • Focused the requirement for permanent registration on persistent publication by an open standards body.
  • Noted in provisional submission template that a proposal may come from a working group.
  • Allowed for fuller contact information under change controller.

03d 19-Feb-2002:
  • Improved wording of submission process.
  • Indicate that there should be IETF consensus that publication would harm the technical infrastructure, for publication of a provisional entry to be blocked.
  • Adjust registration criteria and procedures so that corresponding entries cannot appear simultaneously in the permanent and provisional listings.

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

02a 22-Jan-2002:
  • Merged with HTTP header registry proposal.
  • Move initial registrations to separate documents.

02b 29-Jan-2002:
  • Editorial revisions.

A.6 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.7 draft-klyne-msghdr-registry-00

00a 27-Sep-2001:
  • Document initially created.



 TOC 

Appendix B. Todo

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



 TOC 

Full Copyright Statement

Acknowledgement