moore(_at_)cs(_dot_)utk(_dot_)edu (Keith Moore) wrote on 21.09.01 in
<200109212157(_dot_)RAA18853(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu>:
Problem is, absent good design review and an agreed-on specification,
reuse of existing fields can cause interoperability problems.
Precedence, Priority, and Return-Receipt-To are all examples.
Sure, you don't register a header unless there is paper somewhere that
describes the proper way to use it. That could always include an internet
draft in the case of a provisional registration.
We need more than documentation to use headers widely, we need good design.
And experience suggests that fields designed by individual implementors
aren't suitable for widespread use.
How about a registry that says:
1. In general: this is just a registry, it neither endorses nor ... bla
bla bla ...
1a. If you want advice about headers, these IETF mailing lists are
probaply appropriate: ...
1b. If you want to register a new header, or change an existing
registration, here is a form, fill in the blanks and send it to ...
1c. You are strongly encouraged to write at least an informational RFC
about any header you register (much better than pointing to any other
documentation); advice on how to do that is at ... (and if you're
considering a *new* header, see 1a!)
2. For every entry, has (at least) the following fields:
a. Standardization status (standard, proposed standard, experimental,
proprietary, cooperating-subnet, internal-use (or however we want to call
various non-RFC headers), ...)
b. List of RFCs (and possibly currently active drafts) that talk about
this header (even - or especially - those that say "bad idea")
c. List of relevant non-RFC material that talks about this header
(preferrably only if it is not defined by some RFC) - and yes, I do mean
explicitely a different field
d. Contact addresses, if relevant (mainly for non-standards track headers)
That is, the registry is essentially open to all, but *also* open to (RFC
based) comments at any time. If you want to argue that a specific header
(or set of headers) is a bad idea, you can always write a BCP or
Informational RFC and have it referenced in the entry you want to say
something about. (Or, of course, a standards track RFC, if that's
warranted.)
Note that I put standardization status first, list of RFCs next, and only
after that any non-RFC references. That was intentional.
MfG Kai