Re: Relative URL draft 03

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>

Received on Wednesday, 11 January 1995 20:54:14 UTC