Re: HTTP URL to support multiple naming

Jon P. Knight (J.P.Knight@lut.ac.uk)
Wed, 1 Feb 1995 17:44:00 +0000 (GMT)


Date: Wed, 1 Feb 1995 17:44:00 +0000 (GMT)
From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Subject: Re: HTTP URL to support multiple naming
To: kball@Novell.COM
Cc: uri@bunyip.com
In-Reply-To: <9502011712.AA21574@ka.SJF.Novell.COM>
Message-Id: <Pine.3.05.9502011705.J29226-d100000@suna>

On Wed, 1 Feb 1995, Keith Ball wrote:
> 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.  

No problem as far as I can see.  You could run an HTTP server on the IP
side or a NHTP server on the IPX or an AHTP on the AppleTalk side or some
combination.  The proxy gateway that the client hands off methods it
doesn't understand would do the rest for you.

> 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.

Buzz.  You wouldn't have two URLs at all.  Here, maybe an example bit of
HTML will explain it a bit better:

<HTML>
<HEAD>
...
</HEAD>
<BODY>
...
blah blah <A HREF="nhtp://webserver.IS.novell.us/homepage.html">the one
and only link</A> blah blah
</BODY>
</HTML>

Now, the ``webserver.IS.novell.us'' in this case is part of your NDS
namespace, not the DNS.  If this HTML document is processed by a Novell
client that is running IPX and thus understands the nhtp: method and NDS
name resolution, it just goes and does its thing to your server using the
NHTP protocol (which might look similar to HTTP but then again might not). 
All well and good so far. 

An Internet client that only talks IP won't understand the nhtp:
method, but it doesn't need to.  Instead, it is configured to hand nhtp:
method URLs to a Novell/Internet gateway somewhere.  Lets say that that
gateway has the _DNS_ name ipxgate.novell.com.  The IP based client might
then actually use the URL:

http://ipxgate.novell.com/nhtpgate/nhtp://webserver.IS.novell.us/homepage.html

The machine ipxgate.novell.com would take the request and relay the
nhtp://webserver.IS.novell.us/homepage.html part of the URL into the IPX
universe, where webserver.IS.novell.us would return the required document.
Once ipxgate.novell.com receives this document it can return it over the
TCP/IP connection to our IP based client.  It can also cache it if
necessary and do loads of other cool things that proxies can do.  But the
important point is that both the Novell/NDS/IPX client and the
Internet/DNS/IP client have accessed the same resouce using the same URL.

Similarly, you might get an HREF in an HTML document in browser in the
Novell IPX universe that contains an HTTP URL:

<HTML>
<HEAD>
...
</HEAD>
<BODY>
...
blah blah <A HREF="http://hill.lut.ac.uk/People/jon.html">the one
and only Jon Knight</A> blah blah
</BODY>
</HTML>

The IPX based client wouldn't know how to handle http: methods directly, so
it would hand it off to the proxy gateway by embedding the URL in the HREF
in a nhtp: method request:

nhtp://ipxgate.IS.novell.us/httpgate/http://hill.lut.ac.uk/People/jon.html

The machine with the NDS name ipxgate.IS.novell.us then talks to the IP
side of things, makes an HTTP connection to hill.lut.ac.uk and relays the
results back over NHTP over IPX to the requesting client.  Once again both
the Novell/NDS/IPX client and the Internet/DNS/IP client have accessed the
same resouce using the same URL. 

> 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.

I disagree.  I've just gave your original URL
(<URL:http://www.novell.com/@@NDS:webserver.IS.novell.us/homepage.html>)
to my copy of Mosaic and it barfed up as it was looking for a file called
``@@NDS:webserver.IS.novell.us/homepage.html'' on the machine with the DNS
name ``www.novell.com''.  Now I suppose you could have configured your IP
side httpd to convert ``@@NDS:webserver.IS.novell.us'' into / for us IP
types but you might as well have dropped the ``@@'' and just made it a
perfectly legal http: URL.  But what if your server only exists in the
IPX/NDS universe.  We Internet chaps are stuffed then.  We need a gateway.

> 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.

Fine.

> 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.

Eh?  No documents would need editing in my proposal.  You just need to
build some HTTP/NHTP gateways that can act as proxies for the various
browsers on both sides of the divide.  In fact in your proposal your IPX
based clients would be stuffed as they wouldn't know what host to
connect to handle a request from one of the several million existing
http: method URLs.  They'd need all the documents to be modified to have
the new addressing syntax with NDS names (of gateways?) slipped in to all the
URLs.

> 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.

If you've configured your client to resolve names using NDS then I guess
it can also talk NHTP over IP.  If both the client and the server
understand NHTP when its carried over the IP network protocol then fine. 
For outside DNS (and thus I take it HTTP/TCP/IP) based clients your nhtp:
URLs would be passed to the proxy gateway and it would decide what to do
with them.  I'm assuming of course that in the Netware world, a client
that is using higher layer Netware protocols over IP can talk to a server
using the same protocols over IPX (or vice versa) using some other,
Netware specific gateway.  Otherwide I imagine that more than just NHTP
would be broken in the Netware network!

> 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.  

No, the client is configured to pass the entire NHTP URL to the HTTP/NHTP
proxy gateway,  The gateway then has access to your NDS name for the real
server and go get the document.  What's the problem?  All I'm suggesting
is that you do exactly what thousands of people already do with existing
URL methods and existing proxies.  This ain't rocket science anymore.

> 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.

DNS will certainly change internally - the addresses will get bigger for a
start.  Hopefully the DNS names won't though.  The point I was trying to
make is that IP:ng gives you Novell chaps the chance to use the DNS as
well - why have an almost identical but separate naming scheme in the form
of NDS?  

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *