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.
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".
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').
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. 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.
[name squatters]
What about them? It is axiomatic that registries only work when they are
used. Squatters by definition aren't following the process.
Yes, but that wasn't what I meant, I had (domain) name squatters in mind.
Folks intentionally reserving names because they hope to that somebody
else might need them in the future. With "first come first served" (and
neither "RFC required", nor "expert review") it could be possible to
grab names or numbers, and cause intentional conflicts. Likely too
pessimistic, "DSN status codes" don't play in the same league as URNs or
"URI schemes", they're more in the direction of "SASL mechanisms" (that
would be neither RFC nor expert, IMO too permissive).
As usual we're letting the best be the enemy of the good.
Not really. You've good reasons why you insist on "IETF consensus", and
I've (less good) reasons why I like John's carefully hidden loopholes.
Frank