Thoughts on IANA registries

[Julian Reschke <[e-mail]>]

I've had quite a few registry-related discussions in the past few 
months, here's a collection of thoughts related to this topic.

1) Have a registry or not?

Many people take it as a given that once you have an extension point, 
you need a new registry. Not so.

In this space we have tons of registries that already provide stability. 
For instance, WebDAV (RFC 4918) uses extension points all over the 
place, such as for property names, report names, pre/post condition 
names, but gets away without having to define a single registry.

This is achieved by using an URI-based system; all the types mentioned 
above are pairs of (namespace-uri, local-name), just as in XML + 
namespaces. The namespace URI can be just anything you control, be it an 
http URI, a UUID URN, or a URN in the urn:ietf namespace.

And yes, this works very well. What it does NOT do is standardizing the 
access to the definition *for* the extension, nor discovery. This may be 
a problem in some cases, but not always.


2) When setting up a registry, consider experimentation and local uses

So you have decided you *really* need a registry; in this case consider 
experimentation and local uses.

Some registries have provisional branches and/or vendor trees. An even 
simpler approach is to combine the registry with the extension point 
mentioned above; use the registry for "short names", but allow the use 
of URIs as identifiers as well. This allows people to use extension 
element in private/local use without any fear of name collisions. See 
"Web Linking" (RFC 5988), for example.


3) Somebody forgot to define a registry, what now?

This happens. Sometimes, it's not clear when writing a spec whether a 
registry will ever needed. This happened with a few extension points in 
HTTP/1.1 (RFC 2616), such as status codes. I believe that the plan was 
for specs just to use the "updates" relation in the RFC database to keep 
track of these things, but that doesn't scale well, and it confuses 
extensibility with spec evolution.

RFC 2817 (TLS over HTTP) established an IANA registry for status codes 
later on. That was ok, but what turned out to be a really bad idea was 
to make that registry part of RFC 2817. It makes it hard to find, and 
makes updating RFC 2817 difficult; it just combines too many different 
things inside one document.

So if you ever need an IANA registry for an extension point in an 
already published RFC, by all means make it a stand-alone document.


4) Designated Experts

Some registries do not need review, some do. Review can be very 
time-consuming. If you define a registry that needs Expert Review, make 
sure you actually have multiple volunteers who are willing to do this 
for an extended amount of time; otherwise the registry will not work 
well, or not at all.

Note: every time consumers of a registry have a bad registration 
experience, the whole of IANA and IETF gets blamed for it.


5) Visibility and Accountability

For everything that requires review, establish a public, archived 
mailing list. Optimally also run an issue tracker somewhere where people 
can track the status of their registration requests.


Feedback appreciated,

Julian