Re: URL revision

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Wed, 27 Jul 1994 13:00:50 -0500

From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: "Roy T. Fielding" <fielding@simplon.ics.uci.edu>
Subject: Re: URL revision
In-Reply-To: Your message of "Tue, 26 Jul 1994 18:20:45 MST."
<9407261820.aa23854@paris.ics.uci.edu>
Date: Wed, 27 Jul 1994 13:00:50 -0500
Message-Id: <3537.775332050@moose.cs.indiana.edu>

Thus wrote: "Roy T. Fielding"
>Larry writes:
>> This is misconceived. Some programs take URLs. Others will want to
>> accept URLs, URNs, relative locators, and other kinds of specifiers.
>> All the document claims is that it gives the syntax for the thing that
>> is a self-contained reference to a resource.
>
>I am only talking about URLs here -- relative locators are URLs.

Well, it probably will be desirable in the long run to provide a
mechanism for relative URLs to work with URNs. For instance, if you
have a set of related documents (an FTP directory, a space of
hypertext, whatever) it seems more sensible to have a URN for the blob
(or the entry point to the blob) and use relative URLs if you want to
talk about other objects within the blob directly (or portions of
objects within the blob, as is currently if crudely done in URLs with
#tag syntax.) But putting a URN and a relative URL together into a
single object *does* belong in a separate document.

>> The document is 'incomplete' in many senses: most importantly, it
>> doesn't explain how URLs are used in other protocols. However, this
>> doesn't disqualify it from 'draft standard' status. In fact, with
>> mutually interdependent specifications, it's necessary to publish
>> some parts before others.
>
>Some parts, yes, but certainly not those parts upon which the rest
>of the systax and structure of URLs is dependent. This is the equivalent
>of trying to specify a foot, but putting off discussion of the toes
>until a later time. This is a technical issue which simply cannot be
>left out of the standard.

Have to agree; part of the structure (why slashes mean what they mean,
why sometimes you should escape them, etc.) is very dependent on the
idea and implementation of relative locators.

--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>