Network Working Group                                           G. Klyne
Internet-Draft                                              Nine by Nine
Expires: April 26, 2004                                    M. Nottingham
                                                                     BEA
                                                                J. Mogul
                                                              Compaq WRL
                                                        October 27, 2003


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

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 April 26, 2004.

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




Klyne, et al.            Expires April 26, 2004                 [Page 1]


Internet-Draft         Header field registration            October 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Structure of this document . . . . . . . . . . . . . . . . .  4
   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.    Registration procedure . . . . . . . . . . . . . . . . . . .  7
   3.1   Header field specification . . . . . . . . . . . . . . . . .  7
   3.2   Registration templates . . . . . . . . . . . . . . . . . . .  7
   3.2.1 Permanent message header field registration template . . . .  7
   3.2.2 Provisional message header field submission template . . . .  9
   3.3   Submission of registration . . . . . . . . . . . . . . . . . 10
   3.4   Objections to registration . . . . . . . . . . . . . . . . . 10
   3.5   Change control . . . . . . . . . . . . . . . . . . . . . . . 11
   3.6   Comments on header definitions . . . . . . . . . . . . . . . 12
   3.7   Location of header field registry  . . . . . . . . . . . . . 12
   4.    IANA considerations  . . . . . . . . . . . . . . . . . . . . 12
   5.    Security considerations  . . . . . . . . . . . . . . . . . . 13
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
         Normative References . . . . . . . . . . . . . . . . . . . . 13
         Informative References . . . . . . . . . . . . . . . . . . . 13
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
   A.    Revision history . . . . . . . . . . . . . . . . . . . . . . 17
   A.1   draft-klyne-msghdr-registry-07 . . . . . . . . . . . . . . . 17
   A.2   draft-klyne-msghdr-registry-06 . . . . . . . . . . . . . . . 18
   A.3   draft-klyne-msghdr-registry-05 . . . . . . . . . . . . . . . 19
   A.4   draft-klyne-msghdr-registry-04 . . . . . . . . . . . . . . . 19
   A.5   draft-klyne-msghdr-registry-03 . . . . . . . . . . . . . . . 20
   A.6   draft-klyne-msghdr-registry-02 . . . . . . . . . . . . . . . 21
   A.7   draft-klyne-msghdr-registry-01 . . . . . . . . . . . . . . . 22
   A.8   draft-klyne-msghdr-registry-00 . . . . . . . . . . . . . . . 22
   B.    Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
         Intellectual Property and Copyright Statements . . . . . . . 23














Klyne, et al.            Expires April 26, 2004                 [Page 2]


Internet-Draft         Header field registration            October 2003


1. Introduction

   This specification defines registration procedures for the message
   header field names used by Internet mail, HTTP, newsgroup feeds and
   other Internet applications. It is not intended to be a replacement
   for protocol-specific registries, such as the SIP registry [37].

   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 [4].
   HTTP/1.0 [10] and HTTP/1.1 [27] 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 [11] and related specifications. Other Internet applications
   that use MIME, such as SIP (RFC 3261 [37]) 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



Klyne, et al.            Expires April 26, 2004                 [Page 3]


Internet-Draft         Header field registration            October 2003


   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

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

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

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:

   o  A Permanent Message Header Field Registry, intended for headers
      defined in IETF standards-track documents, those that have
      achieved a comparable level of community review, or are generally



Klyne, et al.            Expires April 26, 2004                 [Page 4]


Internet-Draft         Header field registration            October 2003


      recognized to be in widespread use. The assignment policy for such
      registration is "Specification Required", as defined by RFC 2434
      [3], 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 [1].

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

   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 [10]
   and HTTP/1.1 [27] 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 1864 [9], RFC 2156 [14],
   RFC 2183 [15], RFC 2045 [11], RFC 2046 [11], RFC 2557 [26], RFC 2227
   [16], RFC 2231 [17], RFC 2298 [19], RFC 2369 [22], RFC 2421 [24], RFC
   2518 [25], RFC 2617 [28], RFC 2821 [32], RFC 2912 [34], RFC 2919
   [35], RFC 2965 [36], and RFC 3282 [38].

2.2.1 Application-specific message header fields

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

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



Klyne, et al.            Expires April 26, 2004                 [Page 5]


Internet-Draft         Header field registration            October 2003


   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.





Klyne, et al.            Expires April 26, 2004                 [Page 6]


Internet-Draft         Header field registration            October 2003


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 [23] or URN [13],
   and that are also legal in XML [39] 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



Klyne, et al.            Expires April 26, 2004                 [Page 7]


Internet-Draft         Header field registration            October 2003


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

   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.





Klyne, et al.            Expires April 26, 2004                 [Page 8]


Internet-Draft         Header field registration            October 2003


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 Section 3.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.



Klyne, et al.            Expires April 26, 2004                 [Page 9]


Internet-Draft         Header field registration            October 2003


         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:

   o  An IANA considerations section in a defining RFC, calling for
      registration of the message header and referencing information as
      required by the registration template within the same document.
      Registration of the header is then processed as part of the RFC
      publication process.

   o  Send a copy of the template to the designated email discussion
      list [43]. Allow a reasonable period - at least 2 weeks - for
      discussion and comments, then send the template to IANA at the
      designated email address [45]. IANA will publish the template
      information if the requested name and the specification document
      meet the criteria noted in Section 3.1 and Section 3.2.2, unless
      the IESG or their designated expert have requested that it not be
      published (see Section 3.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.

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 Section 3.1 and Section 3.2.2. Some
   reasonable grounds for refusal might be:

   o  There is IETF consensus that publication is considered likely to



Klyne, et al.            Expires April 26, 2004                [Page 10]


Internet-Draft         Header field registration            October 2003


      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 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
   [43].)

   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.




Klyne, et al.            Expires April 26, 2004                [Page 11]


Internet-Draft         Header field registration            October 2003


   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 [45]. 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 3.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 [13])
   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 [43].

3.7 Location of header field registry

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

4. IANA considerations

   This specification calls for:

   o  A new IANA registry for permanent message header fields per
      Section 3 of this document. The policy for inclusion in this
      registry is described in Section 3.1 and Section 3.2.1.

   o  A new IANA repository listing provisional message header fields
      per Section 3 of this document. The policy for inclusion in this
      registry is described in Section 3.1 and Section 3.2.2.

   o  IESG appoints a designated expert to advise IANA whether
      registration criteria for proposed registrations have been
      satisfied.

   o  [[[During the publication process for this document, there are
      IANA-controlled email addresses and URLs to be allocated.  All



Klyne, et al.            Expires April 26, 2004                [Page 12]


Internet-Draft         Header field registration            October 2003


      such references are indicated in this memo by '[[[(some
      description)]]]'. All such text (including this) should be
      replaced or removed in the publication process.]]]

   Initial header registrations are provided by the following companion
   documents:

   o  For mail message headers: Registration of mail header fields [41]

   o  For HTTP message headers: Registration of HTTP header fields [42]

   No initial entries are provided for the provisional registry.

5. Security considerations

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

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.

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.

   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [4]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

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



Klyne, et al.            Expires April 26, 2004                [Page 13]


Internet-Draft         Header field registration            October 2003


         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]   Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC
         1864, October 1995.

   [10]  Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [12]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

   [13]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [14]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
         between X.400 and RFC 822/MIME", RFC 2156, January 1998.

   [15]  Troost, R., Dorner, S. and K. Moore, "Communicating
         Presentation Information in Internet Messages: The
         Content-Disposition Header Field", RFC 2183, August 1997.

   [16]  Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
         for HTTP", RFC 2227, October 1997.

   [17]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
         Extensions: Character Sets, Languages, and Continuations", RFC
         2231, November 1997.

   [18]  Holtman, K. and A. Mutz, "Transparent Content Negotiation in
         HTTP", RFC 2295, March 1998.

   [19]  Fajman, R., "An Extensible Message Format for Message
         Disposition Notifications", RFC 2298, March 1998.

   [20]  Holtman, K., "The Safe Response Header Field", RFC 2310, April
         1998.



Klyne, et al.            Expires April 26, 2004                [Page 14]


Internet-Draft         Header field registration            October 2003


   [21]  Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/
         1.0)", RFC 2324, April 1998.

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

   [23]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [24]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
         - version 2", RFC 2421, September 1998.

   [25]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
         "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC
         2518, February 1999.

   [26]  Palme, F., Hopmann, A., Shelness, N. and E. Stefferud, "MIME
         Encapsulation of Aggregate Documents, such as HTML (MHTML)",
         RFC 2557, March 1999.

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

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

   [29]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [30]  Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer
         Protocol", RFC 2660, August 1999.

   [31]  Nielsen, H., Leach, P. and S. Lawrence, "An HTTP Extension
         Framework", RFC 2774, February 2000.

   [32]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
         2001.

   [33]  Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn,
         "Internet Printing Protocol/1.1: Encoding and Transport", RFC
         2910, September 2000.

   [34]  Klyne, G., "Indicating Media Features for MIME Content", RFC
         2912, September 2000.



Klyne, et al.            Expires April 26, 2004                [Page 15]


Internet-Draft         Header field registration            October 2003


   [35]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
         Namespace for the Identification of Mailing Lists", RFC 2919,
         March 2001.

   [36]  Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
         RFC 2965, October 2000.

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

   [38]  Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.

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

   [40]  Palme, J., "Common Internet Message Header Fields",
         Work-in-progress: Internet draft
         draft-palme-mailext-headers-08, September 2002, <http://
         www.ietf.org/internet-drafts/
         draft-palme-mailext-headers-08.txt>.

   [41]  Klyne, G., "Registration of mail header fields",
         Work-in-progress: Internet draft draft-klyne-hdrreg-mail-01,
         Jun 2002, <http://www.ninebynine.org/IETF/Messaging/
         draft-klyne-hdrreg-mail-01.txt>.

   [42]  Nottingham, M. and J. Mogul, "Registration of HTTP header
         fields", Work-in-progress: Internet draft
         draft-nottingham-hdrreg-http-00, Jan 2002, <http://
         test.mnot.net/http-headers/>.

   [43]  "Mail address for announcement of new header field
         submissions", Mail address
         mailto:[[[ietf-message-headers]]]@ietf.org.

   [44]  "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.

   [45]  "Mail address for submission of new header field templates",
         Mail address mailto:[[[iana-message-headers]]]@iana.org.






Klyne, et al.            Expires April 26, 2004                [Page 16]


Internet-Draft         Header field registration            October 2003


Authors' Addresses

   Graham Klyne
   Nine by Nine

   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

Appendix A. Revision history

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

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

   07a 27-Oct-2003:

      *  Changes in response to feedback from IESG:

      *  Added notes clarifying that this header field registry does not
         supplant the SIP header field registry.

      *  Updated references in cases where cited RFCs have been
         obsoleted (these were all informational references, being part
         of the survey of protocols and specifications that define
         header fields).






Klyne, et al.            Expires April 26, 2004                [Page 17]


Internet-Draft         Header field registration            October 2003


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



Klyne, et al.            Expires April 26, 2004                [Page 18]


Internet-Draft         Header field registration            October 2003


         treated as a separate protocol for registration purposes.

      *  Separated normative references from informational references.
         (Many 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.3 draft-klyne-msghdr-registry-05

   05a 10-Jun-2002:

      *  Updated contact details.

      *  Updated reference to mail header field registration document.


A.4 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.




Klyne, et al.            Expires April 26, 2004                [Page 19]


Internet-Draft         Header field registration            October 2003


      *  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.5 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.



Klyne, et al.            Expires April 26, 2004                [Page 20]


Internet-Draft         Header field registration            October 2003


      *  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.6 draft-klyne-msghdr-registry-02

   02a 22-Jan-2002:

      *  Merged with HTTP header registry proposal.




Klyne, et al.            Expires April 26, 2004                [Page 21]


Internet-Draft         Header field registration            October 2003


      *  Move initial registrations to separate documents.

   02b 29-Jan-2002:

      *  Editorial revisions.


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

   00a 27-Sep-2001:

      *  Document initially created.


Appendix B. Todo

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

   o  Finalize references to initial registrations.

   o  Finalize email address for submission of registration templates.

   o  Finalize web address for registry.









Klyne, et al.            Expires April 26, 2004                [Page 22]


Internet-Draft         Header field registration            October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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 assignees.

   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



Klyne, et al.            Expires April 26, 2004                [Page 23]


Internet-Draft         Header field registration            October 2003


   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.











































Klyne, et al.            Expires April 26, 2004                [Page 24]