To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: Relative URL draft 03
In-Reply-To: Your message of "Tue, 10 Jan 1995 00:42:44 PST."
<95Jan10.004257pst.2760@golden.parc.xerox.com>
Date: Wed, 11 Jan 1995 17:50:58 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id: <9501111751.aa11425@paris.ics.uci.edu>
Larry writes:
> I've been reluctant to wade in with word-smithing, but...
>
> What if we called these things "RRLs" instead of "relative URLs",
> i.e., "Relative Resource Locators"? Though it isn't the current usage,
>
>> The syntax for relative URLs is a subset of that for absolute
>> URLs [4].
>
> but this isn't true, is it? In the sense that every relative URL is an
> absolute URL? The problem is the word "subset". Maybe "the components
> of a relative URL are a subset of the components of an absolute URL".
> (Even that isn't strictly true, because of "..", but it's closer.)
I can get rid of that sentence (or at least not use the term "subset).
Howvever, it is true that every relative URL is a URL. It is a uniform
resource locator, in every sense of all three words. The fact that they
are not described in the same RFC is a political decision, not a
technological one. By rights, RFC 1738 should be called "Absolute Uniform
Resource Locators", or "URL (Part 1)", since that is all it describes.
>> In other words, relative URLs cannot be used within documents that
>> have abnormal base URLs.
>
> There's nothing "abnormal" about "mailto:", it is just not "suitable".
Okay, I'll change that to "unsuitable" (it looked weird to me too).
>> This generic syntax consists of six components:
>> <scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
>
> Uh, the "#<fragment>" isn't part of the URL, exactly, so you have to
> be careful how you say this.
Another political decision. I've done the best tip-toeing around that
issue that is possible without specifying an unworkable (and unimplemented)
system. If there is still a conflict, it will have to be resolved in the
next URL draft. However, since "#" is not allowed in a URL, I don't see it
as a conflict.
>> This is a BNF-like description of the Relative Uniform Resource
>> Locator syntax, using the conventions of RFC 822 [7], except that
>
> If this is the same BNF as in the URL RFC, you should say so.
It isn't -- I added parentheses for grouping non-optional elements.
>> Some URL schemes allow the use of reserved characters for purposes
>> outside the generic grammar given above. However, such use is rare.
>> Relative URLs can be used with these schemes whenever the applicable
>> base URL is restricted to the generic syntax.
>
> "follows", not "is restricted to", don't you think? And "the generic
> syntax" should probably say "as defined in section 2.1".
Yes, both suggestions would be better.
> You might make this clearer if you said "relative-compatible syntax"
> instead of "generic syntax" throughout the document.
Ummmmm, I'll pass on that one -- I think the latter is clearer.
>> For schemes which make use of message headers like those described
>> in RFC 822 [7], a second method for identifying the base URL of a
>> document is to include that URL in the message headers. It is
>> recommended that the format of this header be:
>
>> Base-URL: "<" absoluteURL ">"
>
>> where "Base-URL" is case-insensitive. For example,
>
> Why not
>
> base: "<URL:" absoluteURL ">"
Yes, I almost did that. This would even be better for HTTP.
My only concern was the increased possibility of conflict with other
headers, but I'll change it if no one objects.
> and then you don't have to repeat the advice about linefolding and
> white space.
I think it will be necessary to repeat that advice in any case.
>> g:h = <URL:g:h>
>
> This isn't a legal example, since "g" isn't a registered scheme.
> If you mean "(assuming g is a registered URL scheme)" then say so.
It is a legal example. The generic syntax (and parsing algorithm) does not
make any assumptions about the scheme being registered, nor should it.
>> 5.2. Abnormal Examples
>
> I think you're better of with fewer examples that are explained than a
> long list of ones without explanations. What's abnormal about them?
I could add a brief explanation, but they serve a very useful purpose
in testing implementations.
>> 8. References
>
> I think most of these are unecessary.
You are probably right, but I put so much effort into listing them
that I didn't want to delete them (yet). They'll be gone in the next
version (unless someone wants them to stay in the draft).
>> [4] T. Berners-Lee, L. Masinter, and M. McCahill, Editors,
>> "Uniform Resource Locators (URL)", RFC 1738, CERN,
>> Xerox Corporation, University of Minnesota, December 1994.
>> <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
>
> This isn't the correct citation form for a RFC; in particular, it is
> not a publication of CERN, Xerox, or the University of Minnesota,
> despite the affiliations of the respective editors.
I disagree -- this is the format used by many RFCs (including 1738,
with the exception that I prefer putting the initial first). There
is no "standard" form for RFC references (that I know of). Please
send it to me if I've missed it.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>