On 21.04.2010 23:06, Kim Davies wrote:
Hi all,
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 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.
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. 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.
(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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf