This seems apropos of the civic address extension discussion.
--Richard


-------- Original Message --------
Subject: Thoughts on IANA registries
Date: Sat, 13 Nov 2010 12:50:22 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: IETF Discussion <ietf@ietf.org>

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf