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:
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf