Subject: Re: The UR* scheme registry, Citing URL/URI specs

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Oct 1997 23:35:21 -0800

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.

So, my feeling is that draft 09 is the final URL draft and it should be
sent to the IESG now.  I'd appreciate it if people using/developing the
latest versions of URL-enabled applications could run the tests on

   http://www.ics.uci.edu/~fielding/url/test1.html

and send me the results.  We need to compile a list of implementations
for each URL "feature" in order to progress to Draft Standard.

....Roy

---

From: <[email-masked]>
Date: Thu, 30 Oct 1997 10:21:26 -0500

> Others may feel differently, so give it a look if you care about this

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
controversy:

   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
[email-masked]

---

From: Dan Connolly <[email-masked]>
Date: Thu, 30 Oct 1997 22:50:10 -0600

>    http://www.ics.uci.edu/~fielding/url/uri.txt
Last Modified: Thursday, October 30, 1997 7:26:21 GMT

I just got around to reading this carefully.

> I am not very happy with it,

I am! This is JUST what I need!

In particular, the HTML 4 spec needs
the term URI-reference as described therein.

I'm quite confident that TimBL would prefer to have
his name on this document than on the one with
URL in the title. (I'll get him to confirm if
anybody really cares.)

> since the additional terms tend to cloud

Now... if the editing-fairy will similarly sprinkle URI-dust
on the process draft (and if this document goes forward in
place of the one with URL in the title), I'll be all set!

> sent to the IESG now.

"should be sent..." who does the sending?
you're the editor, and there's no WG chair, so that's you, no?

-- 
Dan
http://www.w3.org/Architecture/

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 1997 00:14:13 -0500

Roy,

mostly looks okay to me.

I think the URN people will want slightly different language
to distinguish between URLs and URNs: e.g. URNs are distinguished
not only because there is an extra resolution step, but also in
the rules for assignment and use that are designed to make them
more likely to be suitable as long-term identifiers.  

In the section on relative URIs, you might want to explicitly
say that some schemes do not use relative URIs.

But that's all I found on a quick glance-through.
If you can tweak the URN description slightly, I'd say ship it.

Would one of the URN group chairs or authors be willing to 
suggest, by private mail to Roy, appropriate wording changes?

Keith

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 31 Oct 1997 15:20:10 -0500 (EST)

> suggest, by private mail to Roy, appropriate wording changes?

I will look at the document.  I will either have specific wording changes
of the nature you suggest, or concrete concerns that I would like to hear
addressed, in consensus-fashion, on the URN/URI mailing lists.

Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

---

From: Dave Raggett <[email-masked]>
Date: Mon, 3 Nov 1997 09:32:17 -0500 ()

On Thu, 30 Oct 1997 [email-masked] wrote:

> 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. 
> 
> argument that URNs are really for humans.

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 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. 

> 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.

Regards,

-- Dave Raggett <[email-masked]> http://www.w3.org/People/Raggett
phone: +44 122 578 2984 (or 2521) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)

---

From: <[email-masked]>
Date: Mon, 3 Nov 1997 12:36:30 -0500

> 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.]

 > 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.

 > names. However this is a useful side-effect and not a fundamental

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
[email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 05 Nov 1997 23:10:43 -0800

I made some minor changes to match the comments received and have
submitted the URI spec as draft-fielding-uri-syntax-00.txt (Nov 05).
As usual, I have created a diff from draft 09 as well; both are
available from

   http://www.ics.uci.edu/~fielding/url/

....Roy