Message-Id: <9409282316.AA04644@ulua.hal.com>
To: Michael.Mealling@oit.gatech.edu (Michael Mealling)
Subject: No "TOP" of the docuverse [Was: URC usage scenarios ]
In-Reply-To: Your message of "Wed, 28 Sep 1994 16:45:45 EDT."
<199409282045.QAA14460@oit.gatech.edu>
Date: Wed, 28 Sep 1994 18:16:30 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <199409282045.QAA14460@oit.gatech.edu>, Michael Mealling writes:
>
>The method I like is that what we do is each resolution server has
>a unique id (what it is doesn't matter). We then have a directory of
>services server that holds all the description URCs for each resolution
>server.
I suggest that any scenario involving a "root" or "top" server is
doomed to fail.
There are two key features to the URN/URC service: high availability
and authentication. If you rely on a "root" server, you create a
single point of failure, which conflicts badly with the goal of
high availability.
> This description URC holds the Publiber Id that is contained
>within the first two fields of a URN. We can then take these fields, hand
>it off to the direcotry of servers to find out which resolution server
>is 'authoritative' for that URN at which point we can find the 'correct
>as correct can be' response for the given URN.
Just keep the security implications in mind... in order to preserve
the integrity of a link, every step in the traversal must be secure.
Keep the number of principals involved in mind.
Dan