To: uri@bunyip.com
In-Reply-To: bajan@bunyip.com's message of Sun, 28 Nov 1993 21:34:32 -0800 <93Nov28.213454pst.2805@golden.parc.xerox.com>
Subject: Re: Minutes for URI
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Nov28.215928pst.2732@golden.parc.xerox.com>
Date: Sun, 28 Nov 1993 21:59:14 PST
>>>>> On Sun, 28 Nov 1993 21:34:32 -0800, bajan@bunyip.com said:
> [Erik Ostrom <eostrom@pepperoncini.gac.edu> writes:]
>> So why do we want URL: in the URL? I know people were opposed to it,
>> there must have been some pretty convincing arguments.
> [Alan Emtage <bajan@bunyip.com> replies:]
> If memory serves, the final argument that shifted the balance was:
> 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.
This argument didn't hold up: the URL prefix is either unnecessary or
insufficient to isolate it from surrounding text: In some contexts it
is unnecesary, as in a attribute-body list or in a <A HREF="...">
context. In other contexts, it is insufficient, as the scan is
necessarily heuristic, with the URL: prefix possibly missing,
mistyped, and, more seriously, no specified end-delimiter available.
If someone has a situation where the 'URL:' prefix is both necessary
and sufficient as a way to `pick URL's in free text', I'd like to hear
it.
> 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 believe this is the only argument that seemed to hold up, that you
wanted URL: to distinguish them from URNs. I was dubious about it the
utility of it, but I thought the requirement was strongly stated.
As far as I could tell, I was the lone voice at Houston objecting,
though, and I didn't want to repeat myself too many times, lest I be
shouted down by the `rough consensus'. (A new meaning for rough...)