Charles,
Thanks for your many thoughtful comments. I'll not respond to all of them
now, but will take them into account when I do another editing pass. What
I will do here is try and pick up on some of the fundamental questions you
raise surrounding this issue.
At 12:02 PM 10/3/01 +0000, Charles Lindsey wrote:
I think you need to say also the benefits this is intended to achieve. I
would describe them as:
[...]
> 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 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.)
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.
>>> My question here is this: does anyone else feel that something more
strongly normative than a catalogue of headers is called for?
>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.
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.)
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.
> 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.
>>> Question: does every standardized header truly have a single defining
document?
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. 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?
> 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).
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?
"General" is too
vague -
I'm not going to disagree with you here, but if the issue threatens to
rathole I'll argue for complete removal of the template entry.
>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.
I tend to agree, and I'll happily pull a table of relevant details from RFC
2076 and updates if there is consensus for this proposal to move
forward. (The registration template is deliberately simple and could be
captured in a simple table.)
Add consideration of the whole provisional registration issue.
Well, I'm happy to hear consideration, but the feedback I got to my
original comments suggested to me that any real value in this proposal
would be in the standard header registrations.
#g
------------------------------------------------------------
Graham Klyne Baltimore Technologies
Strategic Research Content Security Group
<Graham(_dot_)Klyne(_at_)Baltimore(_dot_)com> <http://www.mimesweeper.com>
<http://www.baltimore.com>
------------------------------------------------------------