Date: Thu, 15 Sep 1994 17:18:46 -0400 (EDT)
From: "Steven D. Majewski" <sdm7g@virginia.edu>
To: Michael Mealling <Michael.Mealling@oit.gatech.edu>
Subject: Re: The <URL: Wrapper take 2
In-Reply-To: <199409151931.PAA05252@oit.gatech.edu>
Message-Id: <Pine.A32.3.90.940915162601.23076A-100000@elvis.med.Virginia.EDU>
On Thu, 15 Sep 1994, Michael Mealling wrote:
> Most of the objections have been that it doesn't currently
> work with any existing code.
Dan's objection was that it's redundant and may be confusing to parsers.
My objection was that it's redundant and likely to be just plain
confusing. ( *one* reason being that it will often not work. )
When "URL:scheme://... " was part of the required syntax of a URL,
I didn't think it was less redundant or any prettier, but if that
was going to be the syntax, then "<URL:scheme://...>" made sense
as the "wrapped" version of the syntax. I think dropping URL:
from the syntax, except for the appendix on wrapping in plain text,
but using the wrapped form in the document ( where they are not
meant to be references, so much as examples of syntax ) makes the
whole document more confusing.
> That's not the purpose of an RFC. If we
> wanted to rubber stamp current web practice then we would never have formed
> the URI working group in the first place. Currently its in the Appendix and we
> have concensus of over 99% of the folx on the list.
Where do you get 99% ? Even the last poll, before it was removed from
the required syntax, and moved to recommended appendix wasn't 99%!
I'm not voting to rubber stamp current practice, but the question is,
how is <URL:scheme://...> and improvement over <scheme://...> ?
Or, if you are going to keep <URL:scheme://...>, the put URL: back
in the url syntax and BNF. If you are worried about backwards
compatibility, then make it an optional part of the syntax.
Half-in, half-out, encouraged, but not supported, seems to me to be
the worst choice!
> I even have a version
> of Mosaic that does handle the URL: if the user puts it in there. It ended
> up only being two additional lines of code.
>
I don't doubt that it's a trivial fix for all clients to support it, but
now that it has been "weakened", I think it less likely to be universally
supported, and so. more likely to confuse people by being sometimes
acceptable and sometimes not.
In fact, a good implementation is going to have to consider:
"scheme://..."
<scheme://...>
<URL:scheme://...>
URL:scheme://...
URL:<scheme://...>
scheme://...
URL:scheme://...
So my objection has never been how many lines of code it takes to support.
If you put URL: back into the *syntax*, ( either required or optional ) I
would find it no more aesthetically pleasing or less redundant, however, I
would not object to it being confusing as it is used in the document.
( Well - there would still be the point of things that aren't
really *locators*, like mid:, cid:. One of my unanswered queries to
this list was about hierarchical URL's like:
<imap://mailbox#mid:message-id#cid:mime-content-id>
If I'm going to allow those to be constructed, than am I going to also
allow:
<imap://mailbox#URL:mid:message-id#URL:cid:mime-content-id> ?
But I was saving bringing that up again until I release an
implementation and argue it out on the IMAP mailing list first. )
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics