HTTP URL to support multiple naming services

Keith Ball (kball@kballuw.SJF.Novell.COM)
Tue, 31 Jan 1995 11:29:02 pst

Message-Id: <9501311929.AA04195@ka.SJF.Novell.COM>
From: kball@kballuw.SJF.Novell.COM (Keith Ball)
Date: Tue, 31 Jan 1995 11:29:02 pst
Subject: HTTP URL to support multiple naming services

We have been working further on creating a single HTTP URL that
refers to a document on an HTTP server that is accessible via multiple 
transports and is named within different naming services, such as DNS,
NetWare Directory Service (NDS) and X.500.

We have several requirements in addition to the one above. 

1) First and foremost, the URL MUST work with existing browsers, if the
server is accessible via IP and has a valid DNS name.

2) A URL with the extra naming information must be clearly distinguishable
from a URL without the extra naming information.  It must be easy to
implement a client, server or gateway that handles both URLs.

3) The URL must be usable if no IP or DNS is available, such as IP
with only X.500 or IPX with NDS.  Obviously, existing browsers won't be
able to use these URLs.

4) The URL must support server proxies, the opposite of client proxies
supported today.  The URL needs to support access of a document by a 
client from one environment through an HTTP gateway to a server in 
another environment.  The client and server may be using the same 
name service or the same transport, but neither is directly 
accessible to the other (able to establish an HTTP connection with 
the other) without going through the gateway.

The Proposal

Our proposal is to extend the URL path area with a naming authority
and name fields.  The URL will have 0 or more segments after the DNS
name of the server that are prefaced by a name service ID and  
followed by the server's name in that service.  The DNS name could be
dropped, if IP and DNS were not available on the server.  This would
also prevent existing clients or IP based clients from trying to 
access documents not on the IP internet.

Servers that support this convention, will ignore the naming segments
in the URLs they receive via the HTTP connection.  In addition, clients
that process the extra naming service information may drop the 
additional leading naming segments when they send the URL in the HTTP 

General Format

I have selected some characters that seem to be available, based on
the URL RFC (1738), but am not wedded to them. If better characters
are available to use, I would appreciate hearing from you on
what they could be.  The BNF is taken from the RFC and modified to
add in the extra segments (altnames).  I haven't placed in this message
unchanged productions.  Please excuse my BNF naivety. If you have
better BNF, please send it to me.

http  = "http://" [hostport] [ "/" [altnames] [hpath [ "? " search ]]

altnames = altname *[ "/" altname ]

altname  = "@@" nameservice ":" servername

nameservice = 1* uchar 

servername  = 1* [ uchar | ";" | ":" | "@" | "&" | "=" ]

I believe all other characters, not defined explicitly in uchar or
the others, can be provided as long as they are encoded using the
escape sequence, %xx.

The nameservice that we will initially support will be NDS, BINDERY,
and DNS.  NDS and BINDERY are 2 forms of NetWare name service.

An example URL:

I would like to have this considered as an extension to the existing
RFC.  Before I write this up as a draft, I would like to get some
feedback on the proposal.


PS.  Thanks to those of you who responded to my last question.
Keith Ball                       Unix/SMTP mail:
Building 1                      MHS mail: KBALL@NOVELL
2180 Fortune Drive
San Jose Fortune  (
(408) 577 8428
Fax: (408) 577 5855

Novell, Inc.

-- sent via the LAN WorkPlace Mailer