WDIFF

draft-klyne-msghdr-registry-02.txt --> draft-klyne-msghdr-registry-03.txt

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

J. Mogul
Compaq WRL
Jan 29,
Feb 19, 2002

Registration procedures for message headers
draft-klyne-msghdr-registry-02 header fields
draft-klyne-msghdr-registry-03

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, August 20, 2002.

Abstract

This specification defines registration procedures for the message
headers
header fields 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, August 20, 2002 [Page 1]

Internet-Draft Message header Header field registration Jan Feb 2002

request@imc.org>.

Table of Contents

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

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

Internet-Draft Message header Header field registration Jan Feb 2002

1. Introduction

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

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

o providing a single point of reference for standardized headers; and widely-
used header field names;

o providing a central point of discovery for established headers, 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 headers 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/protocols.

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

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

Although in principle each application defines its own set of valid
headers,
header fields, 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. header
fields. Listing headers 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.

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

Internet-Draft Message header Header field registration Jan Feb 2002

that purpose.

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

Section 3 defines the message header registry, field name repositories, and
sets out requirements and procedures for creating entries in it. 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 [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 header fields

2.1 Standard Permanent and non-standard headers provisional header fields

Many message headers 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.
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 other headers others have been defined
and adopted ad-hoc to address a locally occurring requirement; some
of these have found widespread use.

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

o Normative A Permanent Message Headers, Header Field Registry, intended for headers
defined in IETF standards-track documents, or those that have
achieved a comparable level of community review. review, or are generally
recognized to be in widespread use. The assignment policy for
such registration is "IETF Consensus", "Specification required", as defined by RFC
2434
[26].

o Provisional Message Headers, intended for any header proposed by
any developer, without making any claim about [26], where the specification must be published in an RFC

Klyne, et al. Expires August 20, 2002 [Page 4]

Internet-Draft Header field registration Feb 2002

(standards-track, experimental, informational or historic), or as
an "Open Standard" in the sense of RFC 2026, section 7 [8].

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 assignment policy
for registration
of recording 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 repository tracks the syntax, semantics or type of field-
values. Only the field-names and field-names, applicable protocols and status are
registered; all other details are specified in the defining
documents referenced by registry 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)
Internet-draft) SHOULD be accompanied by updates to the corresponding registry
repository 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 header fields

RFC 2822 [34] defines a general syntax for message headers, and also
defines a number of headers fields for use with Internet mail. HTTP/1.0 [7]
and HTTP/1.1 [28] do likewise for HTTP. Additional header field 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], [9], RFC 2046 [8], [9], 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 similar message headers include
Internet mail [33][34], NNTP newsgroup feeds [1], HTTP web access
[28] and any other that uses MIME [8] [9] 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 field names,
and not with the details of header implementation in specific
protocols.

In some cases, the same header 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: header used with Internet mail. In other cases, a header field 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, August 20, 2002 [Page 5]

Internet-Draft Message header Header field registration Jan Feb 2002

is generally the case for MIME headers header fields with names of the form
'Content-*'.

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

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
header. field. For normative headers, entries in the Permanent Message Header Field
Registry, this proposal MUST be published as an
RFC. RFC, or as an Open
Standard in the sense described by RFC 2026, section 7 [8].

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

Further, the "." character is reserved to indicate a naming sub-
structure and MUST NOT be included in any registered header field 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 field name
are restricted to those characters that can be used without escaping in a URI
[24] or URN [15], namely upper- or lower-
case lower-case ASCII letters, decimal
digits, "(", ")", "+", ",", "-", "=", "@", ";", "$", "_", "!", "*"
and "'". Of course, a header field name must also conform to any applicable
rules of the protocol(s) with which it is used. Many headers

Some field names may find some use in conjunction with XML [39], in which case [39]. In these

Klyne, et al. Expires August 20, 2002 [Page 6]

Internet-Draft Header field registration Feb 2002

cases, the name characters should 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 field may be contained
in the defining document, or prepared separately.

3.2.1 Normative Permanent message header field registration template

An header registered as a Normative in the Permanent Message Header Field Registry
MUST be defined
according to "IETF Consensus" rules (per published as an RFC 2434 [26]), and MUST
have a name which is or as an "Open Standard" in the sense
described by RFC 2026, section 7 [8], and MUST have a name which is
unique among all the Normative Message Headers registered permanent field names 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

PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
The name requested for the new header. header field. This MUST conform to
the header field specification details noted above.

Applicable protocol:
Specify "mail", "http", "news", "mail" (RFC 2822), "http" (RFC 2616), "news" (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" or "historic",
according to the type and status of the primary document in which
it is defined.

Author/Change controller:
For internet standards-track or experimental specifications, 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 Postal address, home page URI, telephone and
fax numbers may be included.

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

Klyne, et al. Expires August 20, 2002 [Page 7]

Internet-Draft Header field registration Feb 2002

Related information:
Optionally, citations to additional documents containing further
relevant information. (This part of the registry may also be used
for IESG comments.)

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 only requirement main requirements for a header field to be registered as a Provisional
Message Header is included in the
provisional repository are that it MUST have a citable specification. specification,
and there MUST NOT be a corresponding entry (with same field name and
protocol) in the permanent header field registry.

The registration submission template has the following form.

PROVISIONAL MESSAGE HEADER REGISTRATION FIELD SUBMISSION TEMPLATE:

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

Internet-Draft Message header registration Jan 2002

Header field name:
The name requested proposed for the new header. header field. This SHOULD conform to
the
header field name specification details noted above.

Specification document(s):
Reference to document(s) that specifies

Status:
Specify: "provisional". This will be updated if and when the
header for use with
the indicated protocol. An indication of the relevant sections
MAY also be included, but registration is not required. subsequently moved to the permanent
registry.

Author/Change controller:
The name and name, email address address, and organization name of the submission
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
repository entry. Postal address, home page URI, telephone and
fax numbers may 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 IANA message header registry 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

Klyne, et al. Expires August 20, 2002 [Page 8]

Internet-Draft Header field registration Feb 2002

of the relevant sections MAY also be included, but is not
required.

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 means:
methods:

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 then processed as part of the RFC publication
process.

o Sending 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 registration template to IANA at the
designated email address [44]. IANA will publish the template
information if the requested name and the specification document
meet the criteria noted, unless the IESG or their designated
expert have requested that it not be published (see next section).

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 above. Some reasonable grounds for
refusal might be:

o There is IETF consensus that publication is considered likely to
harm the Internet technical infrastructure in some way.

o Disreputable or frivolous use of the registration facilities.

o The proposal is sufficiently lacking in purpose, or misleading
about its purpose, that it can be held to be a waste of time and

Klyne, et al. Expires August 20, 2002 [Page 9]

Internet-Draft Header field registration Feb 2002

effort.

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 [8], section 7) is sufficient grounds for
publication in the permanent registry.

To assist IANA in an email determining whether or not there is a sustainable
objection to the any registration, IESG MAY nominate a designated
email address [45]. expert
to liaise with IANA will register the message header if the
requested name and the specification document meet about new registrations.

The IESG or their designated expert MAY require any change or
commentary to be attached to any registry entry.

The IESG is the criteria
stated.

3.4 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 IESG-
approved RFC Open Standards specification for a Normative Permanent
Message Header, Header Field, or on request of the indicated author/change
controller for a Provisional Message Header.

In addition, 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
registration may Field
Repository entry MAY be requested by the IESG.

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

Internet-Draft IESG or designated expert.

IANA MAY remove any Provisional Message header registration Jan 2002 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 [44].

It is intended that entries in the Normative Permanent Message Header Field
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

Klyne, et al. Expires August 20, 2002 [Page 10]

Internet-Draft Header field registration Feb 2002

Permanent Message Header registry, 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

3.6 Comments on header definitions

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

3.6 [43].

3.7 Location of message header field registry

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

4. IANA considerations

This specification calls for:

o A new IANA registry for normative permanent message headers header fields 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 repository listing provisional message headers header fields
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] [41]

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

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 a previous version of this memo by the many denizens of

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

Internet-Draft Message header Header field registration Jan Feb 2002

6. Acknowledgements

the IETF-822 mailing list.

The authors also gratefully acknowledge the contribution of those who
reviewed
provided detailed review of earlier versions of this memo: Charles
Lindsey, Dave Crocker, Pete Resnick, [[[...]]]

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]

[8] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

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

[9]

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

[10]

[11] 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, August 20, 2002 [Page 10] 12]

Internet-Draft Message header Header field registration Jan Feb 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, August 20, 2002 [Page 11] 13]

Internet-Draft Message header Header field registration Jan Feb 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, August 20, 2002 [Page 12] 14]

Internet-Draft Message header Header field registration Jan Feb 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]

[42] 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

[43] "Mail address for announcement of HTTP new header fields", December 1998,
<http://www.research.att.com/~anja/w3c_webchar/http_header.html>
.

[45] field
submissions", <mailto:[[[ietf-message-headers]]]@ietf.org>.

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

[46] field templates",
<mailto:[[[iana-message-headers]]]@iana.org>.

[45] "IANA list of registered repositories for message headers", header fields",
<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/

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

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

Internet-Draft Message Header field registration Feb 2002

Appendix A. Revision history

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

A.1 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 enries,
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.

Klyne, et al. Expires August 20, 2002 [Page 16]

Internet-Draft Header field registration Feb 2002

* Focused the requirement for permanent 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
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.2 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

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

Klyne, et al. Expires August 20, 2002 [Page 17]

Internet-Draft Header field registration Feb 2002

* 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

A.4 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, August 20, 2002 [Page 15] 18]

Internet-Draft Message header Header field registration Jan Feb 2002

Full Copyright Statement

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, August 20, 2002 [Page 16] 19]
----