To: Gordon Irlam <gordoni@home.base.com>
Subject: Re: URL revision
In-Reply-To: Your message of "Thu, 21 Jul 1994 21:54:08 PDT."
<m0qRCcb-0003pLC@acid.base.com>
Date: Fri, 22 Jul 1994 04:01:28 -0700
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Message-Id: <9407220401.aa18204@paris.ics.uci.edu>
Gordon Irlam <gordoni@home.base.com> writes:
[In answer to Dan's question regarding the URL: prefix]
>> Hello? Did I miss it again? WHAT IS THE ARGUMENT IN FAVOR OF THIS?
>
> 1) Useability.
>
> If possible we should try and make it easy for anything we design
> to be used by niave users.
Usable, yes. Redundant to the point of obfuscation, no. I argue that
prefixing all URLs with URL: is LESS usable than not doing so, for two
reasons:
1) It is unnecessary for communication and thus will not be
used consistently (or not at all).
2) It obscures the most important aspect of a URL -- the access
scheme -- such that they become harder to distinguish by sight.
[I could add a third reason -- differing from existing and accustomed
practice -- as a further usabilty issue, but I won't use that excuse here].
Reason (1) is a simple rule of human nature, for which you provide an
excellent example:
> Note that the phone number name space did not specify a common
> prefix, but because it is necessary for people to be able to
> recognize phone numbers from other numbers, by convention people
> have adopted a de facto prefix, Ph.
Which is not used by anyone around here. For instance, my business
card uses tel: and fax: (in addition to http: ). If a "common"
prefix is not used, it cannot be relied on for consistant communication
and thus MUST NOT be part of the standard for the locator.
Note, however, that what you describe here is not a locator prefix.
It is instead a locator wrapper -- i.e. in text situations, it is common
to use some form of {Ph.|Tel|Fax} to bring attention to a phone number.
I have no problem with including URL: as the standard wrapper or
pairwise identifier for URLs (e.g. for whois++, IANA, mail headers, etc.).
However, it is not a part of the URL, just as Ph. is not a part of the
phone number.
Reason (2) is evident when you put a bunch of URL's on the screen.
This is important because URLs are more than a means of automated
retrieval -- they are also a means of shorthand communication regarding
an object's location. In fact, visibility of the scheme name is much
better when whitespace is inserted between the URL: wrapper and the URL.
If you were going to write a URL down on a napkin and pass it to someone
else who knew what a URL was, would you prefix it with URL:? I wouldn't.
> 2) Namespace design.
>
> If a name space has a common prefix it makes it easier to integrate
> it with other name spaces. It will usually be possible to construct
> a new name space as the union of two name spaces, without having
> to make either one of the name spaces sub-ordinate to the other.
>
> Eg. it might be nice to be able to construct the union of the URL
> name space and a file system name space. Then I could call open()
> with either a file name or a URN, and obtain a handle on the
> relevant object. If neither name space uses a prefix, the chance
> of a collision is much higher, and you might not be able to determine
> from which name space a object comes just by looking at its name.
Again, I disagree. The namespace of a UR* is the access method. Without
knowledge of it, the UR* may as well be just another word. This is equally
true of both URLs and URNs, because what comes after the URN: is (supposedly)
the naming authority. Furthermore, it creates an artificial split
between name spaces at a time when it has yet to be proven that their
exists any split between those spaces.
....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>