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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf