Date: Tue, 13 Sep 1994 14:41:48 -0400 (EDT)
From: "Steven D. Majewski" <sdm7g@virginia.edu>
To: Owen Rees <rtor@ansa.co.uk>
Subject: Re: <URL:...> considered harmful
In-Reply-To: <9409131143.AA15208@plato.ansa.co.uk>
Message-Id: <Pine.A32.3.90.940913142443.16880D-100000@elvis.med.Virginia.EDU>
On Tue, 13 Sep 1994, Owen Rees wrote:
> I feel it is important to have a recommended delimiter. Of the possible
> options, the <URL:...> form seems to me to be the least inconsistent with
> existing practice - it cannot be a valid "msg-id" or "route-addr" as defined
> in RFC-822 (":" is a "special" so MUST NOT occur unquoted). Using "<...>" to
> "indicate the presence of a one machine-usable reference" is quite plausible.
> Parentheses indicate comments and square brackets indicate domain literals in
> RFC-822 so using either of these seems doubtful.
>
URL: <scheme://...>
Also has a ":" ending the scheme part, so it can't be a msg-id or
route-addr.
<scheme://...> and "scheme://..." are already widely used.
( as is whitespace delimited URL's, but you have raised valid
objections against them. )
Lynx and Mosaic don't currently accept URL:scheme://...
It seems less problematic to make the wrappers "<" & ">"
with the URL: recommended and optional. That would seem
to fit current practice and code even better.
Better yet, change it to "URI: <scheme://...> "
which would match a valid HTTP header which has the same meaning,
and change the HTTP syntax to accept that syntax ( with the
"<" ">" wrappers. ) and encourage clients to accept wrapped or
unwrapped locators. This would make the recommendation stronger,
and might mean that it is actually used.
>
> In summary my position is: a recommended (rather than required) delimiter is
> needed, the current proposal works, nothing with fewer problems is on offer;
> keep the text as it is.
>
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics