To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: URL revision
In-Reply-To: Your message of "Tue, 26 Jul 1994 13:22:37 PDT."
<94Jul26.132250pdt.2760@golden.parc.xerox.com>
Date: Tue, 26 Jul 1994 18:20:45 -0700
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Message-Id: <9407261820.aa23854@paris.ics.uci.edu>
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.
> 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.
> I don't think it is appropriate at this time to try to shoehorn
> relative URLs back into THIS document. I don't believe we need 'a bit
> more study', but keeping the components of the information
> architecture separable seems like a good idea.
This is what I am trying to say: they are not separable components!
The syntax and parsing of relative URLs are dependent on the syntax
and parsing of absolute URLs, and vice versa. They cannot be separated
without specifying the same thing in two different documents, and we
all know why that should not be done with an RFC.
....Roy Fielding ICS Grad Student, University of California, Irvine USA
(fielding@ics.uci.edu)
<A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>