In <200202081446(_dot_)g18EkT913648(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu>
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
What I currently have in mind is something like the following:
1. have a template to request registration of a message header,
much like the templates for content-types, charsets, or URN NIDs.
Actually no. People are too used to filling in Web Templates without
thinking. But yes, there needs to be a clear list of what information needs
to be provided; we want people to have to think about what they are doing
(it's one of those "if you need to ask, then you should probably not be
doing it" sort of things).
the template explains the information that is required in order
to register a header field - including the field name, the purpose
of the field, abnf syntax, security and privacy considerations,
the set of protocols for which the field is intended, etc.
No, that is the detail for the specification, and it is likely to change
as the specification is developed. The only technical requirement should
be a _pointer_ to the latest published spec (ideally an Internet-Draft -
and they certainly change over time).
2. have a single mailing list for public discussion of all
proposed message headers
No, not a single mailing list. A mailing list (or newsgroup or web forum)
for that particular topic. Remember that we hope the principal customers
for this facility will be IETF Working Groups, and they will not thank you
for being forced to discuss the header off their own mailing lists.
Moreover, I cannot think of a mailing list that would be competent to
discuss headers for both email and HTTP.
3. submission of the form causes an announcement to be sent to that
list, opening discussion of that header field.
Ietf-822 would be a good place for announcements :-) .
4. initial review takes place for a fixed period of time - say 2
or 4 weeks.
No, 2 or 4 days. The review is up to the mailing list (if it hasn't being
reviewing it already). All we want initially is time for the "expert" to
stop it, or insist on a disclaimer. or whatever we decide.
5. at the end of the review period a designated expert makes one
of a small number of recommendations:
- field is believed to be non-disruptive and okay for
experimental use, or
- field is insufficiently documented, or
- revision based on review feedback is required, or
- IETF consensus is required before this field can be registered
Essentially he either says
1. this satisfies the requirements of having a specification and a
discussion forum
2. it does not conflict with other ongoing work
3. it has reached the stage where it would be useful to try using it
for real
Or else he says
1. this is dumb/conflicts/is write-only or vanity/better left as X-
2. it should be stopped/require a disclaimer/be referred to IESG
6. "in the wild" observations are maintained separately, and
perhaps, automatically. these are submitted via an emailed
web form. submission of the form causes an automatic reply
to the email address that submitted the form; the sender must
confirm sending the observation before it will be accepted.
If it exists in the wild without proper discussion/documentation, then
someone needs to take it in hand, form a group to discuss it (or take it
to an existing group), prepare a proper spec, and then apply for
registration. All with a clear intent for an ultimate RFC and promotion to
the "full" register.
7. there also needs to be a process for commenting on existing
header fields and their applicability. this might be as
simple as writing a BCP about the header field, but the
information in that BCP needs to be reflected in the registry.
That is the public discussion forum mentioned above.
I would also add
8. There needs to be a clear intent that the thing is to be taken forward
towards an eventual RFC (standards/experimental/informational according to
the nature of the beast), at which point it gets promoted to the "full"
register. An exception might be made for headers that were loose in the
wild, but which were to be permanently deprecated.
--
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