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).
Agreed on the need to get people to think about the information they're
providing. I'm not sure what the best mechanism is. I'd be perfectly
happy if folks had to submit an Internet-Draft and get it published as
an RFC.
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).
Okay, we've had people arguing that we needed to make it easy to register
things so that they would be documented and so that other people could
implement them; now you're saying that we can't expect a specification
to review before we put something in the registry.
IMHO if we put something in the registry without a reasonably final
specification, then the most that the registry should say is "currently
undefined; specification under discussion; deployment discouraged".
We certainly don't need people implementing and deploying an extension
for which there's not a stable and publically available specification.
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.
I could see having a separate list for each of mail, http, and news, but
I disagree that it's a good idea to let each WG be the sole reviewer of its
own fields. WGs that are focused on a narrow topic (say, how to do
fax over email, or how to do printing over http) have shown a significant
ability to be naive about the broader implications of their proposals.
Extensions of the email protocol need to be reviewed by a community
of email experts, not just experts in the field for which the extension
is being proposed. Similarly for http and news.
Also, since the header fields tend to leak between protocols, some
cross-protocol review would also be useful.
I'm also very dubious about using newsgroup or web fora for discussion;
I see this as a good way to limit exposure. Most people I know don't
read usenet anymore, and not many people are going to check a web page
every few days for (if charset and content-type registrations are
any indication) a new header field proposal that might arrive, on
average, once every few months?
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 :-) .
maybe. or maybe a separate list would be better.
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.
2 or 4 days isn't nearly enough. Experts are busy people, and they can
easily go for several days without having enough cycles to deal with
things like this. IMHO 2 weeks isn't really long enough.
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
I think we have very different levels of review in mind. If the purpose
of registering a header field name is just to keep anyone else from
using that field, then a level of review like you propose might be sufficient
(provided that a specification were forthcoming and that the registration
would "time out" if the specification were not stable and available within
a few weeks). But if the purpose is making header specifications available
so that other people can implement them, I don't think that level of
review is anywhere nearly sufficient.
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.
Ideally, everything that is out there would be documented, complete
with an applicability statement (and perhaps a network-accessible
oracle that could tell software to ignore or delete harmful fields).
As a practical matter, somebody has to find time to research and document
those things, and for an applicability statement we need to get consensus,
and this is difficult and time consuming. In my experience, most of the
time required to do this is in doing the research and writing a clear
specification, not in dealing with the publication process. A registry
like we're propsing won't help much, I'm afraid.
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.
I like this idea, but I wonder how we could make it stick in practice.
Keith