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

Michael Mealling (dlaliberte@gte.com)
Thu, 30 Oct 1997 10:21:26 -0500

Date: Thu, 30 Oct 1997 10:21:26 -0500
Message-Id: <199710301521.KAA29234@espion.gte.com>
From: <dlaliberte@gte.com>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: uri@bunyip.com, moore@cs.utk.edu, connolly@w3.org, urn-ietf@bunyip.com,
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
In-Reply-To: <9710292342.aa11475@paris.ics.uci.edu>

Roy T. Fielding writes:
 > Just to see what it would be like, I rewrote the URL spec into a URI spec.
 > The result is at
 >    http://www.ics.uci.edu/~fielding/url/uri.txt

 > I am not very happy with it, since the additional terms tend to cloud
 > the implementation advice.  I could fix that by calling everything a URL
 > except in the Introduction, but it probably isn't worth the effort.
 > Others may feel differently, so give it a look if you care about this
 > issue.

I have mixed feelings about this.  On the one hand, the URI label at
least puts both URLs and URNs under the same abstract umbrella.  On the
other hand, it lends credence to the notion that there is a technical
difference between URLs and URNs.  The only argument for the technical
distinction in this draft is:

   A URN differs from a URL in that at least one name resolution pass is
   required in order to access a resource, thus providing the ability to
   ensure the identifier's persistence via a level of redirection. 

I used to argue that this at-least-one-redirection criteria is the only
remaining distinction between names and locations, but I have since then
dropped even that.  I.e., a URN could resolve "directly" to a resource
with no intermediary URL or URC.  (Note: No defense for that claim given
here.)  What gives a URN persistence is the *possibility* to instead
resolve to a redirection to another URI (either another URN or a URL).
But HTTP URLs give you the same possibility.

I would replace the above paragraph with the following argument for a
non-technical distinction:

   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.  We could leave it at that or
add some further explanation, which perhaps gets too close to the

   A URN should be associated with a global, persistent service for
   resolving it or returning a redirection to another URI.

There continues to be confusion (or a difference of opinion at least)
about the key term "resolution".  Those who believe URNs are not
technically different from URLs think of the process of looking up
resolvers for a URN as just one part of the whole "resolution" process,
whereas those who believe there is a distinction between URNs and URLs
see the look-up-resolvers step as something other than resolution
itself.  They also believe that looking up an identifier in a cache is not
part of resolution, so it is not clear to me what resolution really
could be in their minds.

So until we can agree on what "resolution" is, I expect we won't agree
on URNs vs URLs, or whether URIs are a useful concept as distinct from
URNs or URLs.

Daniel LaLiberte