Message-Id: <9503240004.AA08251@mocha.bunyip.com>
Date: Thu, 23 Mar 95 19:01:38 EST
From: misha@research.att.com (michael rabinovich)
To: mshapiro@ncsa.uiuc.edu, uri@bunyip.com
Subject: 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