# Re: <URL:...> considered harmful

Daniel W. Connolly (connolly@hal.com)
Tue, 13 Sep 1994 00:09:09 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Marc VanHeyningen: "Re: <URL:...> considered harmful"
- Previous message: Andrew Pam: "Re: <URL:...> considered harmful"
- In reply to: Marc VanHeyningen: "Re: <URL:...> considered harmful"
- Next in thread: Owen Rees: "Re: <URL:...> considered harmful"
- Reply: Owen Rees: "Re: <URL:...> considered harmful"
- Reply: Steven D. Majewski: "Re: <URL:...> considered harmful"
- Reply: Marc VanHeyningen: "Re: <URL:...> considered harmful"

    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

- Next message: Marc VanHeyningen: "Re: <URL:...> considered harmful"
- Previous message: Andrew Pam: "Re: <URL:...> considered harmful"
- In reply to: Marc VanHeyningen: "Re: <URL:...> considered harmful"
- Next in thread: Owen Rees: "Re: <URL:...> considered harmful"
- Reply: Owen Rees: "Re: <URL:...> considered harmful"
- Reply: Steven D. Majewski: "Re: <URL:...> considered harmful"
- Reply: Marc VanHeyningen: "Re: <URL:...> considered harmful"