ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
If folks get used to register their new header fields specified in I-Ds
it can help to avoid collisions. And if they don't use it it won't help,
with effects as noted in the subject of this thread.
Exactly. And this means that the goal of any registry is first and
foremost to encourage its use, even if that involves constructing the
registry in a way that may admit race conditions. And the only
meaningful measure of the success of any registry is whether or not it
gets used.
Maybe it wasn't clear, I'm not against the status code registry, quite
the contrary. With thousands of RFCs it's very important to organize
this huge repository for ordinary folks who have read less than say 100
RFCs. Maybe RFC 5000 will be a new STD 1, I'd appreciate it.
No, that was quite clear.
I only don't share your optimism about this registry as improvement for
more potential collisions. IFF avoiding collisions is your main goal,
and if you want the "expert review" model (two IFs), then I'd say "copy
3864".
My optimism for using a conventional registry to address this set of problems
is based on numerous past cases where registries have helped eliminate
collisions or duplications.
I don't share your optimism regarding the provisional registry approach simply
because the (admittedly fairly) small amount of running code we have says the
approach isn't working. Copying proven approaches is one thing, copying
approaches that appear to be in trouble is quite another.
Otherwise, if you think that a good "collision detection" already helps
to avoid most collisions, then I'd say "stay away from 'expert review',
use the simpler 'RFC required' model" (or maybe 'IETF review').
I could certainly live with any of these, however, I don't share your pessimism
towards expert review. While there have been some problem cases (the charsets
registry is the obvious apps-related example), there are plenty of other cases
where the approach has worked (I may be biased, but IMO both the current media
types and language code registries have been handled reasonably well).
In the specific case of media types, the problem historically was essentially
the same as the one the current header registration process has - people
didn't/don't use it. It took a major revision of the media type registration
process to make it _much_ more user-friendly to get people to use it. I suspect
the same is going to be needed to have a header registration process that
actually works - my guess is we'll need to streamline the entire process to get
adoption, likely eliminating the entire provisionaal registry mechanism as we
go. However, I'm willing to wait a little longer before suggesting that we do
this.
But this brings up another point, which is that processes and procedures have
changed dramatically over time, making comparisons to how things worked more
than a few years back quite dubious in a lot of cases. Many if not
most of the past problems with IANA registry processing, including but not
limited to management of expert reviews, have been eliminated by IANA's
adoption of a ticket system. Things just don't slip through the cracks the way
they did 3-4 years ago. And recent changes (some only a few months old) have
tightened things up even more.
For the problems that remain, the really interesting question is why expert
review works for some things and fails for others. From what I've seen the
problem arises when the review process is infrequently used and is for whatever
reason difficult to perform. There is no indication that enhanced status code
review is going to be difficult, and while there's no chance it will reach the
frequency of media type registrations, it doesn't appear to be on the "once in
a blue moon" track either.
only actual results matter, and we're not seeing those, at least not yet.
One obstactle with RFC 3864 was to initialize the bureaucracy, convince
IANA that they're supposed to handle this, let IANA convince the IESG
that the IESG has to appoint an expert, and let the IESG convince the
author that he's the expert also on this review list.
Some of this may have been valid criticism in the past, but almost none of it
is relevant now, due in large part to the way IANA works with the RFC Editor
during the publication process. To the extent there are problems in the future,
they're going to be with unusual procedures, which likely still applies to the
provisional registry approach.
For the "expert
review" model there has to be a volunteer for this job, and the author
might be considered as the obvious choice. Maybe my extrapolation based
on Graham and you as experts isn't correct. Otherwise Tony can take it
as fair warning, if he picks this model instead of "RFC required" or the
IETF variation of this theme.
The author is indeed the obvious choice.
Ned