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