[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 3864

Network Working Group                                           G. Klyne
Internet-Draft                                         MIMEsweeper Group
Expires: July 30, 2002                                     M. Nottingham

                                                                J. Mogul
                                                              Compaq WRL
                                                            Jan 29, 2002


              Registration procedures for message headers
                     draft-klyne-msghdr-registry-02

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



Klyne, et al.             Expires July 30, 2002                 [Page 1]

Internet-Draft         Message header registration              Jan 2002


Table of Contents

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






















Klyne, et al.             Expires July 30, 2002                 [Page 2]

Internet-Draft         Message header registration              Jan 2002


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:

   o  providing a single point of reference for standardized headers;

   o  providing a central point of discovery for established headers,
      and easy location of their defining documents;

   o  discouraging multiple definitions of a header name for different
      purposes;

   o  helping those proposing new headers discern established trends and
      conventions, and avoid names that might be confused with existing
      ones;

   o  encouraging 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.
   Listing headers together reduces the chance of an accidental
   collision, and helps implementers find relevant information.  The
   message header registries defined here serve that purpose.






Klyne, et al.             Expires July 30, 2002                 [Page 3]

Internet-Draft         Message header registration              Jan 2002


1.1 Structure of this document

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

   Section Section 3 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 ad-hoc
   to address a locally occurring requirement; 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:

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

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




Klyne, et al.             Expires July 30, 2002                 [Page 4]

Internet-Draft         Message header registration              Jan 2002


   Neither registry tracks the syntax, semantics or type of field-
   values.  Only the field-names and applicable protocols 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 Proposed Standard RFC by a
   Draft 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:

   o  RFC 2076 [11], as updated [40], contains a list of commonly used
      message headers, and

   o  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



Klyne, et al.             Expires July 30, 2002                 [Page 5]

Internet-Draft         Message header registration              Jan 2002


   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.



Klyne, et al.             Expires July 30, 2002                 [Page 6]

Internet-Draft         Message header registration              Jan 2002


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




Klyne, et al.             Expires July 30, 2002                 [Page 7]

Internet-Draft         Message header registration              Jan 2002


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

   Author/Change controller:
      The name and email address of the author, and person who may
      authorize changes to or retraction of the registration.

   Related information:
      Optionally, citations to additional documents containing further
      relevant information.


3.3 Submission of registration

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

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

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



Klyne, et al.             Expires July 30, 2002                 [Page 8]

Internet-Draft         Message header registration              Jan 2002


   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

   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:

   o  A new IANA registry for normative message headers per section
      Section 3 of this document.  The policy for inclusion in this
      registry is described in sections Section 3.1 and Section 3.2.1.

   o  A new IANA registry for provisional message headers per section
      Section 3 of this document.  The policy for inclusion in this
      registry is described in sections Section 3.1 and Section 3.2.2.

   Initial header registrations are provided by the following companion
   documents:

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

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





Klyne, et al.             Expires July 30, 2002                 [Page 9]

Internet-Draft         Message header registration              Jan 2002


6. Acknowledgements

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

References

   [1]   Horton, M. and R. Adams, "Standard for interchange of USENET
         messages", RFC 1036, December 1987.

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

   [3]   Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header
         Field for Internet Messages", RFC 1505, August 1993.

   [4]   Masinter, L. and K. Sollins, "Functional Requirements for
         Uniform Resource Names", RFC 1737, December 1994.

   [5]   Alvestrand, H., "Tags for the Identification of Languages", RFC
         1766, March 1995.

   [6]   Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC
         1864, October 1995.

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

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

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

   [10]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
         Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
         2068, January 1997.

   [11]  Palme, J., "Common Internet Message Headers", RFC 2076,
         February 1997.

   [12]  Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
         RFC 2109, February 1997.




Klyne, et al.             Expires July 30, 2002                [Page 10]

Internet-Draft         Message header registration              Jan 2002


   [13]  Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
         Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
         1997.

   [14]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

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

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

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

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

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

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

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

   [23]  Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for
         Core Mail List Commands and their Transport through Message
         Header Fields", RFC 2369, July 1998.

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

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

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

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



Klyne, et al.             Expires July 30, 2002                [Page 11]

Internet-Draft         Message header registration              Jan 2002


         2518, February 1999.

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

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

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

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

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

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

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

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

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

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

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

   [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", Internet
         draft draft-palme-mailext-headers-05, May 2001,
         <http://search.ietf.org/internet-drafts/draft-palme-mailext-
         headers-05.txt>.




Klyne, et al.             Expires July 30, 2002                [Page 12]

Internet-Draft         Message header registration              Jan 2002


   [41]  Bernstein, D., "Internet mail field name index",
         <http://cr.yp.to/immhf/index.html>.

   [42]  Klyne, G., "Registration of mail header fields", Internet draft
         [[[draft-klyne-hdrreg-mail-00]]], Jan 2002,
         <[[[http://search.ietf.org/internet-drafts/draft-klyne-hdrreg-
         mail-00.txt]]]>.

   [43]  Nottingham, M. and J. Mogul, "Registration of HTTP header
         fields", Internet draft [[[draft-nottingham-hdrreg-http-00]]],
         Jan 2002, <[[[http://search.ietf.org/internet-drafts/draft-
         nottingham-hdrreg-http-00.txt]]]>.

   [44]  Feldmann, A., "Usage of HTTP header fields", December 1998,
         <http://www.research.att.com/~anja/w3c_webchar/http_header.html>
         .

   [45]  "Mail address for submission of header registration template",
         <mailto:[[[ietf-message-headers]]]@iana.org>.

   [46]  "IANA list of registered message headers",
         <http://www.iana.org/[[[ToBeDefined]]]>.


Authors' Addresses

   Graham Klyne
   MIMEsweeper Group
   1310 Waterside
   Arlington Business Park
   Theale, Reading  RG7 4SA
   UK

   Phone: +44 118 903 8000
   Fax:   +44 118 903 9000
   EMail: Graham.Klyne@MIMEsweeper.com


   Mark Nottingham

   EMail: mnot@pobox.com
   URI:   http://www.mnot.net/









Klyne, et al.             Expires July 30, 2002                [Page 13]

Internet-Draft         Message header registration              Jan 2002


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

   02a 22-Jan-2002:

      *  Merged with HTTP header registry proposal.

      *  Move initial registrations to separate documents.

   02b 29-Jan-2002:

      *  Editorial revisions.


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








Klyne, et al.             Expires July 30, 2002                [Page 14]

Internet-Draft         Message header registration              Jan 2002


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

   o  Confirm that IANA are comfortable with the proposed procedures.
      In particular the uniqueness requirements on registry entries.

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

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

   o  Should the controller of a registration always be the author of
      the corresponding specification.

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













Klyne, et al.             Expires July 30, 2002                [Page 15]

Internet-Draft         Message header registration              Jan 2002


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.



















Klyne, et al.             Expires July 30, 2002                [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/