ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
there's plenty of "running code" in this space - for example, there are
heaven knows how many nonstandard header field in use, but aside from the
attempts by Jacob Palme and other third parties leading up to the current
header registration model, how many independent RFC submissions have
there been by authors seeking to document their header usage?
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.
And the only use of it in an RFC has apparently been the initial "bulk load" of
the HTTP header registry. 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.
It allows to "reserve" header fields with provisional registrations
(example: Archived-At) while they're not yet standardized, it allows
to deprecate non-standard header fields (example: Errors-To), and if
a header field finally makes into an RFC (or similar, but we can ignore
"similar" for status codes), it's added to the "permanent" registry.
Yes, and 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.
With that rules in place the old x.7.8 defined in an I-D could have
been registered provisionally, avoiding the current mess.
Models without a "provisional registry" don't avoid such collisions in
practice, they only avoid the collisions in standards published years
later.
Nonsense. 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". Of course this doesn't work for
field names and 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 - and unless something changes
in the header registry world it may prove not to be sufficient either.
In fact _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.
Ned