ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
BTW, RFC 3864 is an _excellent_ model for an "expert review" registry
The jury is still out on that, but things aren't looking good. RFC 3864
has been out for two and a half years, and in that time there has
apparently been exactly one non-RFC provisional registration: Martin's
Archived-at: proposal.
Meanwhile three, it took some time to kick IANA that they kick the IESG
to appoint an expert reviewer. For JabberID the registration was aborted
after Bruce found that the syntax had issues, IMO related to a bug in the
RFC 4622 URI scheme. Indirectly the JabberID review helped to identify
the 4622 bug.
I have a very hard time beleving the world has stood still in regards
to header field name use for all this time. A far more elaborate
registration procedure than most that's rarely is ever used is NOT an
"excellent" model for anything IMO.
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.
in the fullness of time all of this stuff may prove to be useful and
therefore justified. But little if any of it has so far.
It's one of the many things that can work if folks want it to work. I'm
no big fan of the "expert review" model, experts tend to be MIA or AWOL,
or the review lists stop to work, but when it's anyway used, then adding
"provisional registrations" as a feature where collisions are possible
makes sense.
There are all sorts of ways to define a collision-avoiding registry
that don't involve a provisional registration step. An obvious one is
the "IANA assigns number during the publication process".
Does that work for ideas published only in drafts ? Without an "expert
review", what about name squatters ?
I don't think it is the right approach for extended status codes even
though they are numeric and hence amenable to being assigned this
way. But it is simply not the case that the elaboration of provisional
registration is necessary to solve this problem
I don't see how the draft under discussion solves the collision problem
that triggered its creation.
_in practice_ simply having a registry, even one whose procedues don't
prevent race conditions, eliminates most collisions. The enhanced status
code problem is the result of not having a registry period, as opposed
to not having the right sort.
It would be the same mess if the long forgotten I-D had a proper "IANA
considerations" section requesting a registration. If an expired I-D
is implemented, but the name or number isn't registered, unrelated I-Ds
could run into the same trap. For any enumeration the next (allegedly)
free number is an obvious choice.
If the procedure doesn't help with unintentional collisions I dare not
think about intentional collisions.
Frank