Re: URLs for non-Internet networks?

Kevin Altis (kevin@scic.intel.com)
Wed, 21 Jul 1993 11:48:06 -0800

Message-Id: <9307211849.AA20204@rs042.scic.intel.com>
Date: Wed, 21 Jul 1993 11:48:06 -0800
To: "Bernard D. Aboba" <aboba@internaut.com>, Rob Raisch <raisch@ora.com>
From: kevin@scic.intel.com (Kevin Altis)
Subject: Re: URLs for non-Internet networks?

At 11:28 AM 7/21/93 -0400, Rob Raisch wrote:
>URLs are simply instructions to retrieve a thing. The program doing the
>actual retrieval must know how to carry those instructions out. URLs
>*could* be used to reference objects on other, non-connected networks.
>They would be of little use, though, until there is a wide-spread way of
>retrieving from those nets.

Protocol server/gateways
It would be nice to consider appropriate methods for accessing those items
not directly connected to the Internet. For quite some time I've been
pondering how best to provide a server that speaks IP and Novell (and/or
AppleTalk) so that a network of Novell clients could access Internet
services such as WWW without speaking IP and just as importantly how this
multi-protocol server would allow IP clients and servers to access
information sitting on the non-IP network. The server might communicate
with clients via AppleEvents on the AppleTalk side. This scenario still
assumes a server connected to the Internet. This problem and general issues
apply to accessing the information on networks such as Compuserve, BIX,
GEnie, Prodigy, etc. and other services that don't have more of a link to
the Internet than gatewayed mail, even though they could have this kind of
simulated direct access. Many gateway solutions are probably possible, but
the case of non-IP nets communicating through one or more multi-protocol
servers seems worth pursuing with regards to the web.

Note, that this is also a way of limiting the number of IP addresses needed
for many nets that aren't currently on the Internet, since an address only
needs to be allocated for the server/router (maybe a D or E address?). All
Internet services might not be supported for the client, but major ones
such as FTP, SMTP, NNTP, HTTP, etc. probably would.

ka