Re: The Path URN Specification

	From research!bunyip.com!owner-uri Tue Mar 21 15:12:27 1995
	Received: from research (research.att.com) by allegra.tempo.att.com; id AA06639; Tue, 21 Mar 95 15:12:26 EST
	Received: by research.att.com; Tue Mar 21 15:11 EST 1995
	Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA02519 for uri-out; Tue, 21 Mar 1995 12:42:20 -0500
	Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA02512 for <uri@services.bunyip.com>; Tue, 21 Mar 1995 12:42:12 -0500
	Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
	        id AA09158  (mail destined for uri@services.bunyip.com) on Tue, 21 Mar 95 12:41:53 -0500
	Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08584
	  (5.65a/IDA-1.4.2 for uri@bunyip.com); Tue, 21 Mar 95 11:39:24 -0600
	Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
		id AA02162; Tue, 21 Mar 95 11:38:15 CST
	From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)
	Message-Id: <9503211738.AA02162@void.ncsa.uiuc.edu>
	Subject: Re: The Path URN Specification
	To: uri@bunyip.com
	Date: Tue, 21 Mar 1995 11:38:15 -0600 (CST)
	In-Reply-To: <9503202219.AA29164@mocha.bunyip.com> from "michael rabinovich" at Mar 20, 95 05:11:40 pm
	X-Mailer: ELM [version 2.4 PL23]
	Mime-Version: 1.0
	Content-Type: text/plain; charset=US-ASCII
	Content-Transfer-Encoding: 7bit
	Content-Length: 6728      
	Sender: owner-uri@bunyip.com
	Precedence: bulk
	Status: RO

	But you point out a real problem. With the path scheme, if you can move
	part of the hierarchy to a new server and put the info into DNS, scheme
	you have to contact the original server that used to serve the document
	and it tells you to contact another (ie returns forwarding info).  Plus
	if the ability of a server to serve even the forwarding info degrades -
	were stuck.

	I think this may be a fundamental flaw with hierarchical names.

No, I think this is only a problem if you make server hierarchy part of the
name hierarchy. 

	However, flat namespaces have their problems.

	Lets simplify the discussion and assume that a URN should resolve into
	a URL (rather than the document itself). If a URN is a flat namespace
	(no hierarchy) then how do we find the server that knows how to
	translate the URN into a URL.

	One such system is the handles system from CNRI
	  <http://www.cnri.reston.va.us/home/cstr/handle-intro.html>.
	This system maps a flat namespace to URLs by having a suite of servers
	each of which that knows part of the namespace. The URNs are
	distributed among the servers to attempt to reduce the load on any one
	server.  (The URNs are assigned, perhaps by some hashing mechanism).
	If the namespace grows beyond the capacity of the suite of servers, new
	servers are added and the namespace redistributed among the new suite.

	Clients figure out which server to contact by forming a hash on the URN
	and looking up a server in a list of servers (that it downloads from
	somewhere - a detail). The client then contacts the server and either
	gets the URL, or it is told that it has contacted the wrong server but
	is given the name of the server to contact. If it is the wrong server,
	the client probably downloads a new server hash list so it has a
	correct list. This allows more servers to be added and clients to
	adjust to the new number of servers.

	However, this means that clients may have to contact servers that are
	very remote - or that (a hierarchy of?) caches that replicate the
	namespace would have to be introduced.

If there is no caching or replication, clients will have to contact remote
URN/URL resolution servers anyway, be it a flat or hierarchical namespace.
So, I do not see this to be a problem particular to the flat namespace.
This handles system seems rather close to our own approach, except we
deal with name server overloading differently, and we also do dynamic 
replication of end documents.

	I would point out that phone numbers are not flat - if you allow them
	to be global phone numbers. When you add area-codes and country-codes
	you not only get large namespaces but you have a hierarchy that is used
	to find the service that knows about the phone number. Also, within
	organization you have extensions, which also looks to me like
	part of a hierarchy.

I agree.
	-- 
	Michael Shapiro                   mshapiro@ncsa.uiuc.edu
	NCSA                              (217) 244-6642
	605 E Springfield Ave. RM 152CAB
	Champaign, IL 61820

Michael Rabinovich

Received on Thursday, 23 March 1995 19:04:37 UTC