To: uri@bunyip.com
Subject: hacking at the Gordian knot of wrappers
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Dec17.210627pst.2732@golden.parc.xerox.com>
Date: Fri, 17 Dec 1993 21:06:15 PST
I almost hate to bring this up, but this is one of those issues that
won't go away just by ignoring it, so I thought I'd try this once
more.
People want some reliable way to find URLs in arbitrary byte streams.
This way has to include an indication of what things are URLs and
which things aren't, and where the URL begins and ends.
At some risk of stirring the hornet's nest, I'd like to propose a
specification and wording of it in the standard that might satisfy
more folks:
1. People aren't happy with <> as delimiters in some contexts. What
about allowing more than one kind of delimiter? It's a little more
cumbersome to implement, but since URLs are going to occur in lots of
different kinds of contexts, <> doesn't work in all of them. It would
be better to let there be more than one kind of delimiter.
I'd propose allowing either <>, {}, "", or '' around the URL.
2. I think the problem I have with including 'URL:' as *part* of the
URL is that, when my program prompts me for 'URL:', I don't want to
have to type in 'URL:' into the prompt that is asking for the URL.
That is, we should have the specification separate what the `URL' is,
and then say "in any encoding of any data, message, stream, binary,
the URL should be delimited.
Then, include a URL prefix as well as one of the delimiters.
Now, what about if the prefix is allowed to be either URL: _or_ URL=,
and that it can occur either inside or outside the delimiters.
E.g., if your URL is foo://host/string, you write
<URL:foo://host/string> or URL="foo://host/string" or
'URL:foo://host/string' etc.
Note, for example, that HTML could be extended to include
<A URL="foo://host/string"> </A>
as a kind of link. Gopher might want to say
URL:"http://host/string"
Note that I would urge requiring 'URL' to be all caps, and that no
space occur before or after the : or =.