Message-Id: <9311290352.AA05858@gac.edu>
To: bajan@bunyip.com (Alan Emtage)
Subject: Re: Minutes for URI
In-Reply-To: Your message of "Sun, 28 Nov 1993 18:24:51 EST."
<9311282324.AA15643@mocha.bunyip.com>
Date: Sun, 28 Nov 1993 21:52:48 -0600
From: Erik Ostrom <eostrom@pepperoncini.gac.edu>
> In order to pick up URL's in free text (eg, a mail message) it would
> have to be tagged. Otherwise the scanner would have to be able to
> recognize every possible URL access method. This was considered
> infeasible.
Hm, this sounds familiar... When I made this argument on the list, I
believe it was suggested that URLs in free text should be given a
wrapper, like <http://foo.bar.com/hi-there.html>, since for useful
embedding you need an end-of-URL marker as well as a beginning-of-URL
one.
Within the wrapper, I would argue (although others disagree) that you
want some kind of direct indication of whether the identifier is a
URL, a URN, or whatever. But I don't think this is part of the URL,
or URN. I can picture something like <URL
http://foo.bar.com/hi-there.html>, where whitespace separates the
identifier class from the class-specific information.
The point is, if you see URL:http://foo.bar.com/hi-there.html, just
lying there in free text, you can't tell where it ends, unless you do
some kind of gross punctuation thing like require a space between the
URL and the comma. So you need some other way to identify it, which
means that you can get along without the prefix. And putting the
string "URL:" in the URL in any context where the identifier is
_known_ to be a URL is just redundant.
> I believe that somebody also made the point that if we were going to have
> the other UR* prefixed (URN: for example) then it seem for consistency
> that URL: would be the way to go.
I guess I suspect that the arguments against the URL: prefix apply
equally to the URN: prefix.