Re: URLs for non-Internet networks?

Bernard D. Aboba (aboba@internaut.com)
Tue, 3 Aug 93 10:29:06 -1000

Date: Tue, 3 Aug 93 10:29:06 -1000
From: aboba@internaut.com (Bernard D. Aboba)
Message-Id: <9308032029.AA00701@internaut.com>
To: uri@bunyip.com
Subject: Re: URLs for non-Internet networks?

In response to some of Tim's points:

>1. Sometimes the address, sometimes the subject, and sometimes
>the body are used to encode the request in various combinations;

Sure, trying to handle all the possibilities might
be cumbersome. But just supporting body-enclosed text would
probably satisfy 80% of the cases and not be too burdensome.
As masinter@parc.xerox.com said:

"I think 'mailing list access' URLs aren't any more cumbersome than
'mailto'. It's basically a 'mailto' where more of the message is
filled out."

>2. It is very slow compare to "Real OnLine" resources and
>so people would be led into clicking on things which
>they wouldn't have bothered with had they known; (minor
>problem) and basically everyone with mail server will think
>they have done their job of putting things on line
>when in fact they could do much better;

I think we have made a big leap here. Just because I have advocated
adding mail-servers to the URL does NOT mean that I think that W3 or
other interactive applications should be required to support them. My
primary interest was to allow the adding of non-Internet resources to
a future resource directory system, which will probably be based on
URNs and URLs.

>3. When the mail comes back, it is difficult to filter it
>out and extract it. If all mail servers guaranteed
>to make use of a "In Reply to" field to tie
>the response to the request, then an application
>could in principle be hooked in so that when the
>document had been once retrieved it was cached and then accessible
>as part of the web. But it is really hairy. There is
>no well-defined machine-usable protocol.

Again, this might be an argument for not supporting this within
a particular application, until an "In Reply to" field were
supported, but not for excluding use from the URL standard.