Message-Id: <9409130509.AA06650@austin2.hal.com>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Subject: Re: <URL:...> considered harmful
In-Reply-To: Your message of "Mon, 12 Sep 1994 23:20:42 CDT."
<16569.779430042@hound.cs.indiana.edu>
Date: Tue, 13 Sep 1994 00:09:09 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <16569.779430042@hound.cs.indiana.edu>, Marc VanHeyningen writes:
>>
>>If this feature is so valuable, why has it not been implemented and
>>deployed by now? URL's have been around for 2 years. Nobody seems
>>to need anything more reliable than whitespace to delimit URLs in
>>actual practice. If they do need more reliability, they use some other
>>format besides plain text.
>
>Therefore, we should not create a more reliable scheme, because if it
>needed to be done somebody would have done it already? I don't get
>this.
Yes, we should create a more reliable scheme. But we shouldn't
write it in stone until we've got some experience with it. I have
some experience with the <URL:...> scheme, and it's almost all bad.
Until the benefits of the mechanism clearly outweigh the costs,
we have no business standardizing on <URL:...>.
>>>> "What about long URLs?" you might ask. Well, they don't work in plain
>>>> text. They just don't.
>
>Why not? Can they be made to?
It's possible that they could be made to, but it's such a hassle that
it's generally not worth it. If an application requires reliable
transmission of long URLs, plain text is just not the answer.
>>(URL: ftp://cnri.reston.va.us/internet-drafts/draft-ietf-uri-url-07.txt )
>
>Um... OK, I give up... parentheses are better than angle brackets
>because why?
Because they're not as overloaded in the same contexts as <>'s. But
the real point is to put whitespace around the URL because that works
today and will probably continue to work.
>>>> It's a tedious, error-prone situation with no widely deployed
>>>> solution. Emperical arguments to the contrary are welcome.
>
>Therefore, no attempt to solve it should be made?
Attempts to solve it should. Attempts to standardize should not.
>>Is the following
>>a URL or a message id:
>>
>> <URL:my-scheme://foo.bar/abc@foo.com>
>>
>>It satisfies the syntax of both, since the path syntax of my-scheme
>>might allow '@' characters.
>
>So, the problem is possible spurious URL identification.
And spontaneous message ID identification. By choosing <URL:...>,
we are breaking existing code that picks message id's out of
plain text. I see no motivation to do this.
> Are you
>seriously arguing that the <URL:...> wrapper has a greater risk of
>this than your implicit "use whitespace as delimiters" approach?
No. I'm arguing that <URL:...> is no better than the undecorated
URL. It _doesn't_ guarantee reliability. It doesn't even improve
it, in practice.
I'm just trying to keep everything as simple as it can be...
Dan