Registration procedures for message header fields
draft-klyne-msghdr-registry-03
I am now reasonably happy with this draft. So it is time to pick some of
the smaller nits. Here goes ...
Abstract
This specification defines registration procedures for the message
header fields used by Internet mail, HTTP, news and other
^^^^
Netnews
applications.
1. Introduction
The primary specification for Internet message 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 header fields
(respectively, the HTTP-header and message-header protocol elements)
for use with HTTP. These specifications also define a number of
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 header fieldss for use within the same namespaces, notably
MIME [9] and related specifications. Other Internet applications
that use MIME, such as newsgroup feeds (RFC 1036 [1]) may also use
many of the same header fields.
I think you need to introduce RFC 1036 on a par with RFC 2822 and the HTTP
specs. Or maybe it will be USEFOR by the time your draft is finalized.
USEFOR defines the syntax of header fields ab initio, though they are
essentially the same as in RFC 2822.
2.1 Permanent and provisional header fields
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
recognized to be in widespread use. The assignment policy for
such registration is "Specification required", as defined by RFC
^^^^^^^^
Required
2434 [26], where the specification must be published in an RFC
2.2.1 Application-specific message headers
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.
Not quite. A header field may be extensible (e.g. in MIME where
Content-Type can have extra 'parameters' added by subsequent standards;
USEFOR is also introducing a similar feature). So a given field might
legitimately have several specifications (RFCs) listed against it (the
later ones UPDATING rather than OBSOLETING the earliest one, to use the
usual IETF terminology).
3. Registration procedure
3.1 Header field specification
A registered field name MUST conform at least to the syntax defined
^^^^
SHOULD (just to cover yourself :-) )
by RFC 2822 [34], section 3.6.8.
Actually, even that is not good enough, because that allows only US-ASCII,
and USEFOR already allows the full 8 bits in ftext. Doubtless there will
be other exceptions in the future for perfectly valid reasons.
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.
It is further RECOMMENDED that characters in a registered field name
are restricted to those 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 field name must also conform to any applicable
rules of the protocol(s) with which it is used.
I would restrict it even further than that (after all, it is only at
SHOULD level). USEFOR restricts it to letters (case-insensitive) digits
and '-' (but SHOULD accept the full RFC2822), and all known headers in all
three protocols already conform to that. I have no doubt that much
software in many places makes that assumption, and we could think of no
good reason to risk extending it further.
Some field names may find use in conjunction with XML [39]. In these
cases, the name characters SHOULD be further restricted to just
letters, digits, hyphen ('-') and underscore ('_') characters, with
the first character being a letter or underscore.
Yes, that would actually be fine as the general RECOMMENDation.
I also think you should exclude any header beginning with 'X-'.
3.2 Registration templates
3.2.1 Permanent message header field registration template
Applicable protocol:
Specify "mail" (RFC 2822), "http" (RFC 2616), "news" (RFC 1036),
^^^^
netnews
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.
I think you also need "deprecated", "obsoleted", etc if that is how the Spec
defines it (otherwise, you have to premit removal from the registry, which
you don't want).
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.
I would have expected experimental specs to refer to the author(s) just
like the informational ones.
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.)
Would this cover the case where, say, USEFOR defines a header that has a
minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
after a '\'). Would the Spec then say USEFOR, but the related say "based
on RFC 2822"?
3.2.2 Provisional message header field submission template
Applicable protocol:
Specify "mail" (RFC 2822), "http" (RFC 2616), "news" (RFC 1036),
^^^^
netnews
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. 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.
I still maintain there MUST always be a discussion forum (whether by mailing
list or otherwise).
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.
I think you have got to allow purely paper documents. There may still be
some standards bodies whose committees meet in oak-panelled rooms and
write out their minutes on parchment in long hand :-) . Certainly, for
example, ISO standards are NEVER available via a URL (they still have
delusions about generating income from selling paper).
3.3 Submission of registration
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 [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).
I doubt IETF will want to set up a special discussion list just for these
templates, and I doubt many people would subscribe to such a list. Better
to use the existing ietf announce mailing list, with discussion on the
existing discussion list. Or maybe make use of the ietf-822 list.
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
effort.
I think you need to include conflict with other ongoing work within the
IETF as a valid ground.
3.5 Change control
It is intended that entries in the 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
Permanent 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.)
But you need to allow that a future standard may obsolete or reinstate a
header, or even change its meaning so that it bears no resemblance at all
to its former self.
4. IANA considerations
Initial header registrations are provided by the following companion
documents:
I think you should only specify the initial permanent registry. Let people
come forward with their own provisional registrations.
o For mail message headers: Registration of mail header fields [41]
It might be better as an appendix to this RFC. In any case, we need to
have a good look at [41] (does it exist yet?) before finalising this
present draft. There is nothing like looking at real cases to spot the
situations you have failed to cover. In fact, perhaps that should be our
next business.
Also, you need to do something for Netnews. RFC 1036 would do for a start,
assuming USEFOR is not ready in time.
o For HTTP message headers: Registration of HTTP header fields [42]
Isn't RFC 2616 enough?
--
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