-local-civic presents an option for local use that follows this principle, with due regard to the needs of the DHCP format and the registry that it requires.
Brian would have us constrain extension. I think that's a fools errand. Seeking to exert control can backfire.
In attempting to protect the extension space, we also raise the bar for basic use. Then we have people either ignoring our advice and extending anyway, or going elsewhere for their civic addresses. Either way, the goal is not achieved.
Even if we do nothing, the option for gaining interoperability remains open. Having multiple formats does provide some justification for limited action.
--Martin
On 2010-11-14 at 06:00:28, Richard L. Barnes wrote:
> 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
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
