Re: HTTP URL to support multiple naming

What if the server can be accessed via multiple transports or known via 
multiple names in different naming systems.  Here you have multiple avenues 
to the same host and the exact same document.  

What I dont want to see is a document reference (anchor) saying:

"click here if you can access this document from NetWare"
 OR
"click here if you can access this document via the Internet"

making the person make a choice of access methods, when they are 
basically the same, HTTP (one over IP and the other over IPX).  Let
the client chose, it knows how it is configured and what is available.

Sort of stealing from a previous message, but it covers why I think
it is necessary to have one URL that points to the same server with
different names and access points.

If it was the same document on multiple servers, then the URN approach is
much better.  This only deals with a document in one location, but 
accessible via different transports or the server known via different
name services.

If you have separate kind of URL for IPX vs. IP HTTP, then the entire 
document base to be published through IP, would need to be moved and 
editted so the references were in a form existing clients could handle.

Here is another scenario, NetWare does run on IP as well as IPX.  However,
I may use NDS to resolve the server's name to an addres from within my 
organization and use DNS from outside.  In both cases, the client connects
to the server with HTTP over IP. How do I make a home page that refers to a 
single document without burdening the user to make a transport decision that
is obvious for the client software.

On a gateway that is acting as an IP front end for an IPX HTTP server, the
client is unaware of the gateway's presence.  It does a normal HTTP GET,
with URL stripped of host name, just providing the gateway with the object 
name.  The gateway doesnt have the document locally, what it requires is the
actual name of the HTTP server that does have the document.  

As for IPng, if the name service doesnt change, why would you need to use
a different DNS name.  If it does change the name service, then the same 
issues exists for HTTP servers that support IP and IPng access.

Keith

> From:          "Jon P. Knight" <J.P.Knight@lut.ac.uk>
> Date:          Wed, 1 Feb 1995 13:21:42 +0000 (GMT)
> 
> Why don't you just define a new method such as nhtp: that is designed to
> work over IPX?  Surely hacking in multiple transports into the existing
> URLs is a bad idea as you'll just have to do it all over again when you
> move to IP:ng along with the rest of us (you are moving right? :-) ).  And
> not to mention that there's more to the WWW than HTTP; are you planning on
> coming up with IPX versions of FTP, gopher, NNTP, etc, etc and change
> those URLs as well? 
> 
> If you used a new nhtp: method to denote Novell's Hypertext Transfer
> Protocol, we Internet types could just set up proxy gateways that took your
> nhtp: URLs encoded inside a normal http: URL and handed them over to the
> Novell side of things for name resolution, binding and communication.  You
> could even do the reverse for IPX clients (ie: configure them to bundle
> all the traditional URLs inside an nhtp: URL and shove it at the
> Novell/Internet gateway).  You can stick what ever wild and wacky naming
> schemes and formats you like inside nhtp: URLs then without the rest of us
> worrying too much.
> 
> As far as I can see that would work, would let you do caching in the proxy
> gateway at the boundary of the two universes, would be invisible to
> clients on both sides and wouldn't need to have the existing HTTP URL spec
> and WWW browsers fiddled with.  Comments? 
> 
> Jon
-----------------------------------------
Keith Ball                       Unix/SMTP mail:  kball@novell.com
Building 1                      MHS mail: KBALL@NOVELL
2180 Fortune Drive
San Jose Fortune  (sjf.novell.com)
(408) 577 8428
Fax: (408) 577 5855

Novell, Inc.

-- sent via the LAN WorkPlace Mailer

Received on Wednesday, 1 February 1995 12:12:41 UTC