# Re: Relative URL draft 03

Larry Masinter (masinter@parc.xerox.com)
Tue, 10 Jan 1995 00:42:44 PST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Christopher Fraser: "Re: Second round for new URL scheme (mailserver)"
- Next in thread: Roy T. Fielding: "Re: Relative URL draft 03"
- Reply: Roy T. Fielding: "Re: Relative URL draft 03"

    To: fielding@avron.ics.uci.edu

    In-Reply-To: fielding@avron.ics.uci.edu's message of Mon, 9 Jan 1995 22:39:01 -0800 <95Jan9.223919pst.2765@golden.parc.xerox.com>

    Subject: Re: Relative URL draft 03

    From: Larry Masinter <masinter@parc.xerox.com>

    Message-Id: <95Jan10.004257pst.2760@golden.parc.xerox.com>

    Date: Tue, 10 Jan 1995 00:42:44 PST

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

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

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

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

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

You might make this clearer if you said "relative-compatible syntax"
instead of "generic syntax" throughout the document.

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

and then you don't have to repeat the advice about linefolding and
white space.

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

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

> If the result of retrieving that directory includes embedded
> relative URLs, it is necessary that the base URL path for that result
> include a trailing slash. For this reason, it is recommended that
> the ";type=d" parameter value not be used.
> 8. References

I think most of these are unecessary.

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

- Next message: Dirk Herr-Hoyman: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Christopher Fraser: "Re: Second round for new URL scheme (mailserver)"
- Next in thread: Roy T. Fielding: "Re: Relative URL draft 03"
- Reply: Roy T. Fielding: "Re: Relative URL draft 03"