RE: uri, urn and info

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