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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf