Subject: Re: Pointing to IANA registries

From: Kim Davies <[email-masked]>
Date: Wed, 21 Apr 2010 14:06:43 -0700

Hi all,

A few comments from the perspective of IANA staff maintaining the website infrastructure: 

a) This is a timely discussion as we have been discussing this very issue internally. The thought was coming up with better guidance on referencing IANA registries in such a way the provides better clarity on what URI patterns are considered dependable. This is recognising that with the multiple formats we now publish of many registries, there are multiple URIs that can point to the same registry data.

b) The classical registry URI patterns have been http://www.iana.org/assignments/%s and ftp://ftp.iana.org/assignments/%s which we preserve to date. I don't think we have any intention of breaking any of these URIs in the future. However, URIs ending with .xhtml etc. are derivative and possibly subject to change.

c) To my mind, a central question is not the preservation of the URI, but what is the expectation of preserving the format of the content at the URI. For most registries this is probably not an issue, but there is probably an assumption the registries at http://www.iana.org/assignments/port-numbers and http://www.iana.org/assignments/language-subtag-registry - to pick on two - will always be of a certain consistent format. As a counter example, we piloted removing the legacy version of the "aodv-parameters" registry last week, so if you go to http://www.iana.org/assignments/aodv-parameters it redirects to the current XML URI of that registry.

d) As part of a long term project that is nearing completion, our intention is to keep the definitive version of all registries in XML format, with any text, HTML etc. versions derivative from that. We have great flexibility in what URIs these XML files and their derivatives are published to, but I suspect would want to retain the ability of phasing out old formats and not being wed to publishing all possible derivates in perpetuity. In fact, the XHTML format may already be a candidate for deprecation with widespread support of viewing the same data in the XML version converted in a browser through client-side XSL. It would be useful to better understand whether the essential ingredient is a URI that works and lists all formats and contemporary URIs, or a URI that preserves the same legacy format, with new file formats under new URI patterns.

kim

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Apr 2010 14:42:56 +1000

For the issues around formats, have you considered using content negotiation?

  http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1

WRT XHTML, it's a candidate for deprecation for a different reason; the W3C is moving away from XHTML as part of the HTML5 effort. Current fashion for this type of problem is to use microformats / RDFa, but that's still work-in-progress from a standards standpoint, AIUI. 

Cheers,

On 22/04/2010, at 7:06 AM, Kim Davies wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Apr 2010 09:01:08 +0200

>    http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1

+1

> ...

As a member of the W3C HTML WG I have to disagree with Mark. HTML5 
defines and maintains both serializations. It *does* spend lots of spec 
space to define tag-soup parsing, yes, but that's simply because that 
format is so broken; the XML variant is still there.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Apr 2010 17:27:42 +1000

I'll defer to Julian on matters of HTML; he's braver than I ;)

On 22/04/2010, at 5:01 PM, Julian Reschke wrote:

> As a member of the W3C HTML WG I have to disagree with Mark. HTML5 defines and maintains both serializations. It *does* spend lots of spec space to define tag-soup parsing, yes, but that's simply because that format is so broken; the XML variant is still there.
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Apr 2010 10:04:42 +0200

> A few comments from the perspective of IANA staff maintaining the website infrastructure:

Appreciated!

> c) To my mind, a central question is not the preservation of the URI, but what is the expectation of preserving the format of the content at the URI. For most registries this is probably not an iss…

Sounds good to me.

 From a spec-authoring point of view, what I'm looking for is something 
I can link to, and people follow that link and get to the actual 
registry. The format in this case is secondary, as long it is something 
their user agent can deal with. (In doubt, conneg may help, as Mark 
pointed out).

Also, registries that require a specific format probably require that 
because they are machine-readable, right? I'm not against it, but be 
careful with it with respect to scaling (and things breaking when the 
resource is not available, as it was the case for the RSS and (X)HTML DTDs).

> d) As part of a long term project that is nearing completion, our intention is to keep the definitive version of all registries in XML format, with any text, HTML etc. versions derivative from that…

(good stuff!)

I think the #1 concern is that the URI should be stable for human readers.

A simple way to achieve this is, as Mark suggested, HTTP conneg; publish 
the URI excl file extension, and serve text/plain, text/html or 
application/xml (with XSLT stylesheet PI) according to what the UA asks 
for. For bonus points, add a Content-Location response header that 
carries the more specific URI.

I think that's actually better than redirecting; the URI people will see 
in the address bar will stay the generic one, and that's what we want 
people to pass around.

Best regards, Julian