Public Identifiers

[Jerome McDonough]

At 06:42 AM 9/21/98 -0500, Steven R. Newcomb wrote:
>> # A URN identifies a resource or
>> # unit of information.  It may identify, for example, intellectual
>> # content, a particular presentation of intellectual content, or
>> # whatever a name assignment authority determines is a distinctly
>> # namable entity.  A URL identifies the location or a container for an
>> # instance of a resource identified by a URN.  The resource identified
>> # by a URN may reside in one or more locations at any given time, may
>> # move, or may not be available at all.
>> 
>> Note especially the last phrase.
>
>The problems with the quotation from RFC 1737 are these:
>
>* Who defines what constitutes a name assignment authority?

The URN working group of the IETF is working on an Internet Draft
addressing the issue of how name assignment authorities are registered
(or not).  Quoting from the draft: "In a nutshell, a template for
the definition of the namespace is completed for deposit with IANA,
and a NID (namespace identifier) is assigned."  The draft contemplates 
three levels of name spaces: experimental, informal, and formal.
Experimental are not explicitly registered with IANA, and take
the form of x-<NID>; no provision is made for avoiding collision
of experimental NIDs.  Informal are registered with IANA and assigned
a number sequence as an identifier, in the format "iana-"<number>
where <number> is chosen by the IANA on a First Come First Served basis.
Formal identifiers are processed through an RFC review process; a template
containing registration information would be sent to urn-nid at apps.ietf.org
to allow for a 2 week discussion period; then the template should be
sent to iana at iana.org.  The template will request a particular NID
string, which is assigned by IETF consensus.  So, essentially anyone
can produce an experimental URN; formal ones are a bit more work.
See the Internet Draft for details.

>* There is an even more problematic statement: "A URL identifies the
>  location or a container for an instance of a resource identified by
>  a URN."  This strongly implies that there must be a URL behind every
>  URN, even if that URL is fictitious or doesn't happen to work.  It
>  also implies that there is some sort of locatable online container.

This does not appear to be what's contemplated for URNs at the moment.
Having spent several long, painful weeks trying to wade through all
of the RFCs and Drafts regarding URNs and name resolution services,
there does not appear to be any requirement anywhere that a URN
resolve to any URL.  This makes sense if you think about it; if you
register the ISBN name space, you're going to have an awful lot of
ISBNs which are not available online, and aren't likely to be.
Granted you probably wouldn't go to the trouble of registering a namespace
with IANA if you didn't contemplate making at least a portion of the items
identified within that space available online, but there's no requirement
that you do so.



Jerome McDonough -- jmcdonou at library.Berkeley.EDU  |  (......)
Library Systems Office, 386 Doe, U.C. Berkeley     |  \ *  * /
Berkeley, CA 94720-6000    (510) 643-2058          |  \  <>  /
"Well, it looks easy enough...."                   |   \ -- /  SGNORMPF!!!
         -- From the Famous Last Words file        |    ||||

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)