Re: URLs on iana.org, was: Draft minutes from TAG telcon of 2008-10-02

On Wed, Oct 8, 2008 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

>
> My understanding is that (as of now) the IANA is unwilling to guarantee
> *anything* about how they serve web content. I'd be surprised if they cared
> about the fine points of the 303 status code; for now they are even
> discouraging use of the registration URLs in specifications (<
> http://tools.ietf.org/html/rfc5226#section-5.1>):
>
>        Note 2: When referring to an existing registry, providing a URL
>        to precisely identify the registry is helpful.  Such URLs,
>        however, should usually be removed from the RFC prior to final
>        publication, since IANA URLs are not guaranteed to be stable in
>        the future.  In cases where it is important to include a URL in
>        the document, IANA should concur on its inclusion.
>
> BR, Julian


Fascinating - thanks for the alert. They are saying in effect that URIs
should not be used to identify things (at least not in RFCs), which is
different advice from what I've heard elsewhere.

Maybe this means we need to set up a mirror for all RFC-referenced
registries elsewhere, with ARK-like resolution of the registered URIs via a
parallel set of locations? (Probably there's already such a thing.)

(This is a classic case of a failure mode I've been concerned about - URIs
that become important to a community, are stored in places that are
difficult or impossible to change, and are then abandoned by the domain
owner - essentially the 404 problem, but with the stakes ratcheted up a
notch or two. I'm predicting trouble along these lines in the next few
years, despite our best efforts at discouraging use of not-so-cool URIs in
such places and encouraging persistent resolution, and will be very
interested to see how the affected community responds.)

Jonathan