Thoughts on IANA registries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]