# Re: URL revision

Roy T. Fielding (fielding@simplon.ICS.UCI.EDU)
Tue, 26 Jul 1994 04:51:42 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: Mailserver URL proposal"
- Previous message: Daniel W. Connolly: "Re: URL revision"
- In reply to: Peter Deutsch: "Re: URL revision"

    To: uri@bunyip.com

    Subject: Re: URL revision

    In-Reply-To: Your message of "Mon, 25 Jul 1994 10:41:19 EDT."

                 <9407251441.AA03381@expresso.bunyip.com>

    Date: Tue, 26 Jul 1994 04:51:42 -0700

    From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>

    Message-Id:  <9407260451.aa02097@paris.ics.uci.edu>

Peter Deutsch <peterd@bunyip.com> wrote:

> I do want to say a word to the issue of relative URLs.
> The output of this working group is designed to be used by
> a wide variety of systems and protocols. In particular, at
> least some of us (and perhaps all of us?) hope that a
> standardized URL will promote interoperability among
> Internet information systems. Now, although WWW _may_ allow
> relative URLs, it is my understanding that the working
> group decided not to support them, as without a specific
> context (as is available in WWW) they are basically
> unusable at this time.

That is not true. They are usable wherever a tuple can be established
which ties the relative URL to an absolute base URL. For a WWW client
(or any client which uses a URL to retrieve an object), that base URL can
default to the current context. For situations which lack that context
(e.g. receiving a message via e-mail or netnews), the content-type of an
object may allow for the base URL to be embedded in that object. That is
the case for HTML (via the <BASE href="..."> element) and could easily be
added to other content-types which expect to use URLs. For others
(e.g. plain text), the specification can simply state that relative URLs
are not considered URLs for those content-types.

In contrast, the current IETF URL document claims that ALL relative URLs are
not URLs and thus do not exist for the purposes of the Internet standard.
This is not only untrue, it is dangerously blind and will lead to anarchy
among "official" URL parsing implementations. The URL syntax is inexorably
bound to the need for relative parsing -- that is why '/' is reserved and why
'//' is used in front of the hostport.

> If we really want to promote interoperability then I think
> we should plan on a comprehensive study of the issues
> involved here before embarking on the task of specifying a
> syntax for relative URLs. I do understand that they have
> proved useful in WWW, but this is _not_ a working group to
> standardize WWW practice. What we come up with must be
> usable throughout the Internet, and I think we would need
> a bit more study and consensus before tackling this
> particular task.

I completely disagree. The current document is incomplete without
the presence of an appendix describing the syntax and parsing of
relative URLs. Without it, the document is unacceptable as a draft
standard and should not be published as such.

A draft standard should contain all the information relevant and necessary
to the thing being standardized. If "a bit more study" is needed, then
let it be done out in the open and visible to those implementing according
to the spec. If changes are called for, changes can be made, but it is
irresponsible to remove from the spec something which is clearly a necessary
requirement of any URL parser.

I will see if I can dig up the appendix used by TimBL in prior revisions
and clean it up later tonight for a proposed addition to the spec.

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

- Next message: Dirk Herr-Hoyman: "Re: Mailserver URL proposal"
- Previous message: Daniel W. Connolly: "Re: URL revision"
- In reply to: Peter Deutsch: "Re: URL revision"