Date: Thu, 15 Sep 1994 13:15:24 -0400 (EDT)
From: "Steven D. Majewski" <sdm7g@virginia.edu>
To: Chris Weider <clw@mocha.bunyip.com>
Subject: Re: The <URL: Wrapper take 2
In-Reply-To: <9409151525.AA24457@mocha.bunyip.com>
Message-Id: <Pine.A32.3.90.940915114705.24273A-100000@elvis.med.Virginia.EDU>
On Thu, 15 Sep 1994, Chris Weider wrote:
> Larry:
> I think I'm going to be a hard nosed dude here: This is the first objection
> I've seen publicly raised to an issue that in my mind was settled more than
> a year ago, [ ... ]
The subject was last brought up July 20 in :
Subject: URL revision
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Jul20.170935pdt.2761@golden.parc.xerox.com>
> 12. The URL: prefix requirement is still controversial, in that there
> are still strong opinions about it. If we were voting (which we were
> not) the votes would have it moved. I'm reluctant to touch this
> without a stronger mandate.
with objections being raised by Dan Connolly and Roy T. Fielding
and others in following messages. The result of those objections
was that Larry moved the <URL:...> recommendation to the appendix.
Looking further back in the archives, I get no impression of a
consensus for <URL:...> - only that folks got tired of arguing
about it. ( Well - I guess that's really the IETF definition of
"consensus" after all! ;-)
So, it's not exactly like Dan has stirred up a long settled matter!
> I haven't seen any compelling arguments against wrappers (sorry Dan)
> and I've already done my compromising on this :^) I think we should leave it in.
Wrappers are a good idea.
BUT:
You can't legislate what people do in plain-text - which is obviously
why it's a recommendation.
<URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
is no clear improvement over he most common existing practice:
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
( my subjective impression entirely, but I'm quoting the .sig line
of someone who switched over to the former from the latter after
voting a preference for <URL:...>
And I haven't seen any compelling arguments to change from the old
style.
I'm not aware of any code that supports <URL:...> ( but maybe I'm
out of date here - correct me if I'm wrong. I haven't looked at
the latest libwww, but I've tried several clients for both
<URL:scheme://...> and URL:scheme://... and none of them accept
it. I do happen to know of code that accepts <scheme://...>. )
HTTP has a "URI:" header which also doesn't allow for
"URI: <URL:scheme://...>" .
If folks want to distinguish what that think is inside the
wrappers, they are likely to use a less cryptic label.
( More people know what "WWW: <scheme://...>" means than URL:,
and I expect that a commercial developers make more consumer
oriented browsers, they'll avoid such acronyms in their
user interface: even plain "Locator" is less cryptic than URL: )
I'm against it on the principle that the tag/name is not part of
the wrapper, and "<URL:" ... ">" as a wrapper just confuses things.
What about URI's that aren't really locators: "URL:urn:..." for
example, and are message-id's and news: or nntp: really *locators*,
or a non-location-specific indicator.
Why not just a paragraph explaining the justification for wrappers,
stating that several forms are in common use: <...>, "...", and
whitespace. Illustrate the whitespace + punctuation problems.
State that "<" ">" is almost universally used for "machine readable
references" - mail-addresses, unique-message-identifiers, and
locators - to set them off from comments or other text, and
encourage software to accept wrapped or unwrapped references.
Since within HTML documents, the double-quote (") delimiters
are used within anchors, general purpose libraries for URL's
ought to be prepared to handle both types of delimiter.
Why muddy the waters by adding Yet Another possible form to handle?
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics