Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs

Dave Raggett (dlaliberte@gte.com)
Mon, 3 Nov 1997 12:36:30 -0500


Date: Mon, 3 Nov 1997 12:36:30 -0500
Message-Id: <199711031736.MAA06164@espion.gte.com>
From: <dlaliberte@gte.com>
To: Dave Raggett <dsr@w3.org>
Cc: uri@bunyip.com, urn-ietf@bunyip.com
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
In-Reply-To: <Pine.WNT.3.95.971103091813.-163571I-100000@hazel.hpl.hp.com>
 <Pine.WNT.3.95.971103091813.-163571I-100000@hazel.hpl.hp.com>

 > On Thu, 30 Oct 1997 dlaliberte@gte.com wrote:
 > >    A URN differs from a URL in that a URN is intended to remain
 > >    globally unique and persistent long after the resource it
 > >    refers to ceases to exist or becomes unavailable. 
 > > 
 > > This non-technical distinction seems to agree with Keith Moore's
 > > argument that URNs are really for humans.

Dave Raggett writes:
 > I am not sure this follows from your definition. For instance,
 > GUIDs are guaranteed to remain globally unique but need never
 > refer to any concrete resource, neither are they Human friendly
 > unless you are particularly good at remembering 128 bit numbers.

I agree with you on both counts.  So the definition should have been
"...long after the resource it refers to, *if any*, ceases...".  The
human friendly issue is different from the issue of the "URN" keyword
that is supposed to indicate to humans (and programs) that the
identifier is *intended* to be persistent, etc, and should therefore be
preferred over lower forms of life.  

[I would argue that it is reasonable for such intent to be expressed for
any URI, and that URN spaces will eventually be obsoleted too, so this
doesn't really buy us anything, but I could live with it because it is
explicitly merely an "intent" as opposed to a strong technical
distinction.]

 > I think the key idea is that such names are guaranteed to be
 > globally unique over a very extended period of time -- i.e. they
 > won't be reused unintentionally for something different, as is
 > quite likely for names based on file system hierarchies. 

I disagree that such a guarantee means anything useful, so I would
replace it with a promise to be good.  Consider that it might be the
correct thing to do to reuse an identifier for something that is not
identical to the original but has equivalent meaning.  Accidentally or
unintentionally reusing an identifier should be avoided, however, and it
is generally not difficult to do once you set your mind to it.

 > > We could leave it at that or add some further explanation, which
 > > perhaps gets too close to the controversy:
 > > 
 > >    A URN should be associated with a global, persistent service
 > >    for resolving it or returning a redirection to another URI.
 > 
 > I don't think this is necessary in all cases. For example an MD5
 > of a document is useful even in the absence of such a service.
 > The uniqueness of a name over space and time certainly lends itself
 > to fault tolerant means to access resources associated with such
 > names. However this is a useful side-effect and not a fundamental
 > property.

I agree.  I tend to be more concerned about the persistent resolution
service since it is difficult to provide in a scalable manner.  By
comparison, persistent uniqueness is trivially easy.

--
Daniel LaLiberte
dlaliberte@gte.com