- From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
- Date: Fri, 10 Oct 2003 17:27:17 +0100
- To: 'Larry Masinter' <LMM@acm.org>, uri@w3.org
Hi Larry: Some comments below in response to your last post. > There is no requirement that URN namespaces have 'persistence of > identifiers as a primary purpose'. The above statement conflicts with this opening passage from RFC 2141: "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers." So, again we are left feeling really confused. Maybe it's just the words that are being used. > Given the (purported and demonstrated) ease of registering URN > namespaces, the fact that the public has not generally availed > itself of the process of registering URN namespaces is no excuse > for establishing another process, especially one which is less > transparent. This would be a moot point given that we were considering a URN namespace - which we are not. One might note in passing that it is precisely because the general public cannot easily navigate the IETF registration process for URI schemes and URN namespace IDs, that some intermediary registration mechanism might be of tangible benefit. > For example, the Internet Draft suggests, in section 4, that > there is a policy that (US) NISO will follow, but it doesn't > articulate the policy, does not document the process, and the > suggested URI for the process > http://info-uri.niso.org/info-uri-policy > yields (at least currently) "Cannot find server or DNS Error". This is a correct observation. The I-D has been published [1] for initial IETF review, while in parallel the "info" Registry is currently being built out and the appropriate policy documents formulated. That said, the I-D has been in the public domain for the last two weeks and we now find ourselves discussing this on a W3C mailing list, instead of on the designated IETF mailing list. We may have miscalculated the process for registration of a URI scheme - it is maybe not so straightforward as one could wish. > So my suggestion is that NISO instead dedicate itself to registering > URN namespaces (with IANA using the documented URN process) > for the namespaces that it would have otherwise registered > as "info" namespaces, and that IETF not proceed with the > publication of this draft. This would be to misunderstand the whole purpose of the "info" URI scheme. NISO through the "info" Registry seeks only to faciliatate registration of public namespaces of interest to its member constituents within the "info" Registry. NISO has no plans, and more significantly, no mandate to register third party public namespaces with the IANA. We also recognize that many of these public namespace authorities have no current designs to engage with the IETF registration process and we are thus frustrated in our attempts to reference information assets from these public namespaces within the URI allocation. It may also be worthwhile noting that registration with the IANA is not a requisite for the existence of a new URI scheme. Apparently the mere use of a URI with a new URI scheme (conformant to the syntax requirements of RFC 2396) confers upon it a life of its own through the simple process of autovivification. RFC 2396, RFC 2717, and the W3C Working Draft "Architecture of the World Wide Web" expressly acknowledge this state of affairs and articulate that registration is highly desirable for various reasons. We, of course, fully subscribe to this view and are currently engaging in this registration process with the IETF. We are especially interested in getting a favourable recommendation from the IESG as we are now finalizing the ANSI/NISO Draft Standard for Trial Use on the OpenURL Framework [2] for a 2003 ballot in which the "info" URI scheme is deployed as a key component in providing for a unified naming architecture based on the global URI naming architecture. Various proposals that we have earlier considered [3] and that have also been suggested to us during the last couple of weeks (e.g. "http", "urn", "tag", "vnd-?") - while each displaying merits and demerits of thier own - do not prove to be workable solutions for our basic requirements. We have sought to consult with relevant parties at all stages of the development of the "info" URI scheme [4]. We are seeking to implement a lightweight registration process for public namespaces which works together with the regular IETF registration process. Tony [1] http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt [2] http://library.caltech.edu/openurl/Public_Comments.htm [3] http://library.caltech.edu/openurl/PubComDocs/Announce/20030626-Bootstrap.ht m [4] http://library.caltech.edu/openurl/PubComDocs/Announce/20030626-Announce-Nam ing2.htm Tony Hammond Advanced Technology Group, Elsevier 32 Jamestown Road, London NW1 7BY, UK <tel:+44-20-7424-4445> <mailto:t.hammond@elsevier.com> -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: 10 October 2003 08:42 To: uri@w3.org Subject: RE: uri, urn and info To return to the discussion of http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt which started all of this: Section 7.2 "Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?" claims, for "info" URIs: Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces. There is no requirement that URN namespaces have 'persistence of identifiers as a primary purpose'. Yes, it is advised that URN namespaces should be persistent. But most of the examples of URN namespaces don't have persistence as their primary purpose. There have been no examples of 'info' namespaces proposed that do not have persistence. There is no requirement that URN namespaces not also have 'locator semantics'. It is only required that URN namespaces have name semantics. Given the (purported and demonstrated) ease of registering URN namespaces, the fact that the public has not generally availed itself of the process of registering URN namespaces is no excuse for establishing another process, especially one which is less transparent. For example, the Internet Draft suggests, in section 4, that there is a policy that (US) NISO will follow, but it doesn't articulate the policy, does not document the process, and the suggested URI for the process http://info-uri.niso.org/info-uri-policy yields (at least currently) "Cannot find server or DNS Error". So my suggestion is that NISO instead dedicate itself to registering URN namespaces (with IANA using the documented URN process) for the namespaces that it would have otherwise registered as "info" namespaces, and that IETF not proceed with the publication of this draft. Larry -- http://larry.masinter.net
Received on Friday, 10 October 2003 12:27:35 UTC