Re: How to add new "protocols" ?

> http:// is clearly well-defined, and should not be overloaded.
> If HTTP over other protocols is desired, the URL should be
> extended to allow the specification, or the protocol name changed
> (http: to something else).
> However, note that such changes require other possible extensions
> to the URL, to allow arbirary names (with ":"'s inside the host
> field), etc.).

Rather than take this approach, how about returning to another 
idea thats been floating round Web circles for a while - URN's.

Basically anything used to retrieve a resource has to be a URL, that 
is there has to be enough information in the identifier to allow the
material to be located. URN's are a bit of a misnomer. The only time 
URNs are really used in the Web is in PICS where the url scheme name
is in fact a name - its meaning arises from the context of its use.
The ability to use the name to locate is merely a usefull byproduct.

There are two workable URN schemes both of which are based on directory 

In the simplest scheme we imagine that search engines such as Alta-Vista
keep MD5 checksums of all the material they process and place it in a 
directory. The directory then allows material to be accessed by the hash 
code, it simply provides a redirect to the nearest source of the material.
Such a scheme provides the main feature required of URNs - the ability to
link to an idea rather than a location. Dynamic text can be encompased in 
the scheme by using hash values in the manner of GUIDs.

A more complex scheme would employ modifications to DNS and possibly the
creation of an additional level of directory service. Basically the DNS
protocol would be extended to add a Web-x record which would allow redirection
of Web requests in a manner analogous to MX records for mail. To request a
page web:// the client would resolve the name,
see if an mx record was provided and if so apply an associated translation
to find the actual server to use.

Either process could be assisted by a number of additional attributes allowing
the "best" server out of a collection to be selected. The simplest attributes 
would be service preference rank and service class. Unless one is performing 
complex database type transactions a cached document is as good as the original
provided one knows how out of date it may be.

In the near future I believe that serious consideration will have to be given 
to the transport of bulk data. For most http work the amount of optimization
of network load is limited because its easy to spend more time moving the data
required for optimization than is downloaded. With motion video this will

It would be nice if a system would allow a resources such as CD-ROMs to
be transparently added to a network. When a CD-ROM was placed on a jukebox
the label could be read and the cd transparently "mounted" as a local
network resource. Such a scheme would allow seemless linking to material on

Returning to the original issue. I believe that we will find it essential
to add some type of redirection layer into the Web similar to that
described above. URLs are the "IP addresses" of the Web - they are bound to
the network topology in a maner that is undesirable in the long run. At the
point that this layer is added it is vital that the transport protocol 
issue is considered. The next time there is a need to upgrade IP the Internet
will be mainly based on URLs, they will be a critical leverage point allowing
a smooth upgrade path.


Received on Tuesday, 18 February 1997 14:09:59 UTC