Network Working Group G. Klyne
Internet-Draft MIMEsweeper Group
Expires: March 28, 2002 Sep 27, 2001
Registration procedures for message headers
draft-klyne-msghdr-registry-00
Abstract
This specification defines registration procedures for the message
headers used by Internet mail, newsgroup feeds, HTTP and other
Internet applications.
Aren't you supposed to say somewhere what classification of RFC this is
intended to become? I guess it would be "Best Current Practice", but I am
not sure.
1. Introduction
This specification defines registration procedures for the message
headers used by Internet mail, newsgroup feeds, HTTP and other
Internet applications.
I think you need to say also the benefits this is intended to achieve. I
would describe them as:
1. To serve as an index/directory of established headers, enabling their
meaning and defining documents to be located.
2. To prevent accidental re-use of a header field-name for some different
purpose.
3. To enable those proposing new headers to discern already established
trends and conventions, and to avoid field-names that differ only slightly
from existing ones.
The primary specification for Internet message headers is the
Internet mail message format specification, RFC 2822 [21], but there
are many other Internet standards track documents that define
additional headers within the same namespace, notably MIME [6] and
related specifications. Other Internet applications that use MIME,
such as newsgroup feeds and HTTP web access, also use many of the
same headers.
I think you need to make explicit reference to RFC 1036 (news) [[[and
USEFOR]]] and RFC 2616 (HTTP) here.
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 headers. The message
header registry defined here serves that purpose.
2. Message headers
2.1 Standard and non-standard headers
Many message headers are defined in standards-track documents, which
means they have been subjected to a process of community review and
achieved consensus that they provide a useful and well-founded
capability. Many other headers have been defined and adopted for
private use.
The registry defined here is intended for headers defined in IETF
standards-track documents, or those that have achieved a comparable
level of community review. Thus, the assignment policy for
registration of new message headers is [[[ IETF consensus | Standards
action ]]], as defined by RFC 2434 [17].
A registry for non-standards-track message headers is at best
informational, and at least two such sources of information already
exist:
Indeed, but then this proposed IANA registry is at best informational.
o RFC 2076 [7], as updated [24], contains a list of commonly used
message headers, and
I think the intention of this registry should be to supersede the function
of RFC 2076 and its extensions.
o Dan Bernstein maintains a list of standard and non-standard mail
message headers [25].
2.2 Definitions of message headers
RFC 2822 [21] defines a general syntax for Internet message headers.
It also defines a number of headers for use with Internet mail.
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 [4], RFC 1864 [5], RFC 2156 [11], RFC 2183 [12], RFC 2045
[6], RFC 2110 [8], RFC 2298 [13], RFC 2369 [14], RFC 2421 [16], RFC
2821 [20], RFC 2912 [22] and RFC 2919 [23].
Make sure any obsoleted RFCs are not in your list.
Internet applications that use (some of) these message headers
include Internet mail [20][21], NNTP newsgroup feeds [1], HTTP web
access [18] and any other that uses MIME [6] encapsulation of message
content.
I don't see the distinction you are trying to make here. RFC 2616 [18] is
in the business of defining headers just as much as RFC 2822, 1036, or any
of the others in your first list. It belongs with the first lot. Note also
that HTTP is not restricted to web access. It can be used to retrieve any
"resource", whether web related or not.
3. Registration procedure
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. This proposal MUST be published as an RFC.
Right. You did not actually say standards track there. I would have no
problem with Experimental Protocol RFCs, and I would also like to see
provisional registrations (with some stringent rules). But we can discuss
that.
A registered header name MUST conform 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.
I think you say "MUST at least conform...", and then indicate that
individual protocols MAY specify more stringent requirements. For example,
RFC 2616 restricts field-names characters quite severely, and USEFOR will
be even more severe; RFC 1036 REQUIRES a blank after the colon (and USEFOR
will follow it).
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 [15], namely upper- or lower-case ASCII
letters, decimal digits, "(", ")", "+", ",", "-", "=", "@", ";", "$",
"_", "!", "*" and "'".
The RFC 2616 set is neither a subset nor a superset of that lot :-( . I
actually see no need for anything other that letters, digits and '-', and
I know of no existing counter-example. It may also be worth noting that
only ASCII letters and digits are permitted in field-names. That is true of
both RFC 2822 and USEFOR (even though USEFOR allows UTF-8 elsewhere in
headers).
The name of a registered header MUST be unique; if an name is already
assigned to an existing registered header name, some other name must
be chosen.
OTOH, this does not prevent some other protocol from reusing the same
name, possibly with modified syntax, parameters, etc, but hopefully for
some related purpose. For example, RFC 2616 does some markedly different
things with its Content-Type header (but well within the spirit of MIME).
Header names beginning with "X-" or "x-" are reserved for private
use, and MUST NOT be registered or defined normatively by a standards
track RFC.
or defined in ANY RFC for that matter, including Experimental Protocols.
3.2 Registration template
The registration template for a message header is typically contained
in the defining document, or may be prepared separately.
The registration template for a message header contains the following
information:
Header name:
The name requested for the new header. This MUST conform to the
header specification details above.
Specification document:
A reference to the standards track RFC that defined the header.
There will be several specification documents for a given header. I think
the register has to state that "this header is intended for use in
protocols A, B, and C, and then give the document that defines its use for
each of those protocols. Of course, in some cases, the same defining
document may be referred to for two or more protocols.
Even for a single protocol, there may be more than one document (for
example a basic definition, plus some later extension that provides
additional functionality).
Intended use:
Specify "general", "mail", "news", "http", "MIME" or cite any
other standards-track RFC defining the protocol with which the
header is intended to be used.
Hmmm! I think you need to stick just to "mail", "news" and "http" (plus
any totally separate ones that may appear in the future). "General" is too
vague - better to list the same RFC against two or more protocols if it
applies to them all. And the application of "MIME" may vary considerably
between protocols (for example, there is no Content-Transfer-Encoding in
HTTP). Again, USEFOR will include a list of MIME headers that are
allowed in news articles, and refers to the existing MIME RFCs for their
meaning. However, it does then go on to curtail their usage in various
minor ways.
So a question arises as to which RFC you refer to for a protocol that
just does such minor tinkerings/clarifications.
Related information:
Optionally, citations to additional documents containing further
information relevant to the defined message header.
Yes, that may be a way to cover the "tinkerings/clarifications" issue.
3.6 Location of message header registry
The message header registry is accessible from IANA's web site [27].
4. Initial registrations
This specification calls for initial registration of all message
headers defined in existing standards-track documents. A list of
such headers can be found in RFC 2076 [7] and updates [24]. Section
Section 2.2 of this document contains a list of standards-track
specifications that define message headers.
[[[Need to provide list of headers+documents here for initial
registration?]]]
I think it would be far better to include an Appendix setting out in full
the initial IANA registration. At the very least, that would force us to
consider all the special-case problems that will inevitably arise, and
maybe to fine-tune our document in consequence.
Appendix B. Todo
(This section to be removed on final publication)
o Finalize choice of RFC 2434 assignment policy. See section
Section 2.1.
Add consideration of the whole provisional registration issue.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5