In
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20011003182724(_dot_)03a26750(_at_)joy(_dot_)songbird(_dot_)com>
Graham Klyne <GK-lists(_at_)ninebynine(_dot_)org> writes:
At 12:02 PM 10/3/01 +0000, Charles Lindsey wrote:
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.
This touches of the normative vs informational purpose for the registry.
The registry itself is informational (it just tells you where to look).
But the RFCs it points to are normative, and so the registry acquires its
authority indirectly.
The reason I feel that a registry is in order, rather than just an
informational database, is that I am finding situations where I want to
leverage the existing set of standards-track definitions in another
specification; I want to be able to include existing header names and
semantics by reference. (My immediate application is representation of
message metadata with URIs used to identify header values.)
I think that is essentially my reason #3.
When thinking about this draft, I considered a two-part registry for
normatively defined headers, and a separate catalogue of informally defined
headers. But I felt that there was limited value in duplicating existing
efforts, and a simple catalogue of headers-in-use really didn't need to be
an IANA registry. Rather, I felt the useful focus was on those that had
been "assigned" by consensus action in the IETF.
If you want to be able to say "do not use that header, it is bogus", then
you need a registry that is pretty complete. In particular, it needs some
way for the man to make his header non-bogus (albeit with some hoops to
jump through first, which should certainly include provision for
discussion within the Internet Community). That is why I would support a
"provisional" section in the registry (or some other word with similar
effect).
My question here is this: does anyone else feel that something more
strongly normative than a catalogue of headers is called for?
See above. If it is not in the Registry, then it is bogus. If it is in the
registry, then it is whatever the Registry says it is (or what the
document pointed to by the registry says it is).
3.1 Header specification
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.
Yes, I was leaving open the choice between "standards action" or "IETF
consensus"; I tend to favour the latter, as long as it's obvious from a
published RFC whether or not it represents such consensus. (I wanted the
IANA assessment to be dead easy: the key registration items are the header
name and defining RFC, which should be easy to check. Certianly, a
standards-track RFC definition is.)
There is provision in RFC 2434 for "Designated Experts" appointed by the
Area Director to approve registrations. We might make use of that
mechanism for non-standards-track entries, perhaps including my
"provisional" ones. Or maybe there are other mechanisms - the details would
have to be discussed.
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).
Hopefully, there will be just one *defining* RFC.
No, life is not so simple. For example, RFC 2616 defines Content-Type from
the ground up. If RFC 2045 were to disappear in a puff of smoke, RFC 2616
would not be affected. USEFOR does make more use of RFC 2822 for the
headers that are common to both, at least for the syntax. But even there
the semantics are (re)defined in full.
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.
If this is true, then I don't think a single registry can suffice here. I
think it's fine if different protocols use or constrain the use of a header
in different ways, as long as the underlying definition is clear and
definitive. You mentioned the example of HTTP and Content-type: in this
case, I think the basic meaning is clearly defined by RFC 2045; RFC 2616
may refine its interpretation in the context of HTTP, but I don't think it
changes the definition.
No, it gives an entirely separate definition, which just happens to follow
the original in most (but not all) respects.
Question: does every standardized header truly have a single defining
document?
No.
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).
Good point.
In this case, the RFC index will show that the original specification is
updated or obsoleted by subsequent documents, so I think it can be argued
that the combination of "active" documents provides a single, coherent
definition.
Not so. To understand everything you are allowed to write in a
Content-Type, even just for Mail, you need RFC 2231 as well as RFC 2045
(because it extends the syntax of 'token'). But RFC 2231 does not
obsolete RFC 2045.
I'd better re-phrase the previous question:
Question: does every standardized header truly have a single coherent
definition, tracable from a single initial defining RFC?
Still no.
Hmmm! I think you need to stick just to "mail", "news" and "http" (plus
any totally separate ones that may appear in the future).
Well, I was in two minds whether or not to include this in the template. I
don't think it's really needed, but I thought it might be sufficiently
helpful to justify the small increase in "paperwork".
Question: is this a useful part of the registration template? If so,
what are the appropriate categories?
I think that mechanism will be essential. Here, for example, is how I
would register Content-Type. Note that for each protocol there is a
primary definition, and possibly several secondary definitions (i.e.
extensions).
Header Field-name: Content-Type
Protocol: Mail
Primary definition: RFC 2045
Secondary definition: RFC 2231
Protocol: Netnews
Primary definition: RFC 2045
Secondary definition: [[[USEFOR]]]
Protocol: HTTP
Primary definition: RFC 2616
--
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