# Re: URL revision

Larry Masinter (masinter@parc.xerox.com)
Tue, 26 Jul 1994 13:22:37 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Roy T. Fielding: "Re: URL revision"
- Previous message: Marc VanHeyningen: "Re: Mailserver URL proposal"
- Next in thread: Roy T. Fielding: "Re: URL revision"
- Reply: Roy T. Fielding: "Re: URL revision"

    To: fielding@simplon.ics.uci.edu

    In-Reply-To: fielding@simplon.ics.uci.edu's message of Tue, 26 Jul 1994 11:33:51 -0700 <94Jul26.113408pdt.2762@golden.parc.xerox.com>

    Subject: Re: URL revision

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

    Message-Id: <94Jul26.132250pdt.2760@golden.parc.xerox.com>

    Date: 	Tue, 26 Jul 1994 13:22:37 PDT

Roy says:
> 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.

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

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.

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.

- Next message: Roy T. Fielding: "Re: URL revision"
- Previous message: Marc VanHeyningen: "Re: Mailserver URL proposal"
- Next in thread: Roy T. Fielding: "Re: URL revision"
- Reply: Roy T. Fielding: "Re: URL revision"