Perhaps things have settled down sufficiently for me to express an
opinion...
I am not an IANA weenie. But I think registries should register
things.
We have a decent amount of running code (for example,
http://www1.ietf.org/mail-archive/web/ietf/current/msg35953.html) that
says our attempts to limit what gets deployed by limiting what gets
registered don't work reliably.
Exactly. FWIW, media types, email header field names, and charsets are all good
examples of other ways things can go wrong.
Now, the vast majority of the registries we have are ones which for whatever
reason aren't terribly popular: Additions to the registry are rare and so is
use of unregistered values. (Take a look at the list of IANA registries and
you'll find dozens of these.) We may like to think of these as registry success
stories, but getting scaling considerations "right" is easy when no scaling is
needed.
Then there are some where only a few values are registered but several other
values are in common use. A good example of one of these was the protocol name
registry used in email WITH fields: For the longest time only "SMTP" was
standardized but a small set of other values were frequently used. RFC 3865
changed that, but writing this sort of RFC and getting it through the process
turns out to be surprisingly hard, so much so that most registries with this
particular problem never get dealt with. (An nearby example of one that hasn't
been cleaned up are email VIA fields.)
Then there are the registries where there's an escape hatch for private values.
Sometimes this is sufficient to prevent use of supposed-to-be-registered values
and sometimes it doesn't. For example, most private SMTP extensions - and there
are a bunch of them - have elected to the X-prefix naming convention marking
them as private use. OTOH, email header fields that don't begin with "X-"
abound that from context are clearly carrying private-use information. (This
problem is so prevalent that there was no consensus to continue having the "X-"
convention in RFC 2822.) Or consider media types, where the initial
registration procedures were overly onerous and where for whatever reason
people didn't like seeing "X-", so literally hunderds of unregistered values
came into widespread use, use which continues to this day.
The bottom line is that despite being informed by many years of experience we
aren't nearly as good at this stuff as we seem to think we are.
...
What I would like to see is a clear distinction between IANA as a
registry and the IETF as a protocol standards organization.
Agreed. This would help a lot.
...
I also note that one of the many "wireless is special" things I've
seen in the past decade was the WAP Interim Naming Authority (WINA),
now resurfacing as the Open Mobility Naming Authority (OMNA) (see
http://www.openmobilealliance.org/tech/omna/index.htm). There are
probably other pseudo-IANAs I don't know about. Our choke-hold on the
parameters the world uses isn't quite as tight as it needs to be in
order for us to use IANA as an enforecment tool.
Well, we like to talk about how the network we have helped create routes around
problems at many levels, but we seem to be unable to comprehend that sometimes
we're the ones that are perceived as being the problem. It is hardly surprising
given the very mixed results we've had with our own registries that other
registries have sprung up. And since I have no real expectation that we're
going to clean up our act as a result of this or any other discussion, this
sort of thing is bound to continue and even accelerate.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf