Message-Id: <9404011959.AA15630@ulua.hal.com>
To: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Subject: Prospero as URN implementation
In-Reply-To: Your message of "Thu, 31 Mar 1994 23:57:44 MST."
<199404010657.XAA19291@collie.acl.lanl.gov>
Date: Fri, 01 Apr 1994 13:59:22 -0600
From: "Daniel W. Connolly" <connolly@hal.com>
In message <199404010657.XAA19291@collie.acl.lanl.gov>, "Ronald E. Daniel" writ
es:
[Lots of interesting stuff about URNs and related issues... which
reminds me..]
There was some talk long ago about using prospero for IIIR. e.g.
"New papers available on Prospero"
< http://www.acl.lanl.gov/URI/archive/uri-archive.messages/241.html >
I've been reading over the prospero papers and doc, and I downloaded
the source and tinkered with it for a while.
See:
< ftp://prospero.isi.edu/nfs/pub/prospero >
I'm not as up-to-speed on whois++, but prospero seems like a great
candidate for a name service:
* It's based on a lightweight reliable protocol (ARDP)
over UDP rather than TCP. This should save bandwidth
for this budding but soon to be ubiquitous service.
* Authentication and authorization are already integrated.
Kerberos and local password mechanisms are implemented.
>Up to now, the discussion of the URN->URL mapping service has concentrated,
>naturally enough, on that one operation. However, my belief is that there
>are several other operations that need to be considered. When we consider
>them, they imply certain things about the syntax of URNs, and also about
>the contents of URCs. My hope is to generate some discussion on what
>services, in addition to the URN->URL lookup, are needed for the
>URN service. This will let us make better choices on representations,
>etc. for URNs and URCs.
Yeah! Amen! Agreed! Let's design the objects in terms of their
operations and then design some representations!
> The example I always use when introducing URNs to
>someone who knows about URLs is the "roaming URL problem" - moving a
>file or changing a host name can invalidate thousands of
>documents across the world. While I don't think a URN server should
>snoop on the directories containing various resources, I do think that
>the needs to be a way of telling it that things have moved.
Prospero supports forwarding pointers, time-to-live on links, and
other mechanisms to address this problem.
>The functional
>requirements include global scope,
Prospero has a global naming system, but it encourages the use of lots
of local naming systems. The global prospero namespace probably
doesn't have the properties we want in URNs, but we could reserve one
such "virtual namespace" to be the namespace of URNs.
> global uniqueness, persistance,
>scalability, extensibility, etc.
These are supported by various features of prospero.
>What operations? Well, for
>starters, how is a resource published and registered with the system?
Excellent question. Hmmm...
>How does a publishing authority grant permissions to a sub-authority?
Hmmm... yes... authorization to modify the namespace is a biggy. Does
whois++ support this kind of thing? Prospero does. It's a lot
like the DCE cell director service, now that I think about it -- but
without all the overhead of DCE.
>Since a major motivation for URNs is to cure the "roaming URL" problem,
>how do we register a resource's new location with the service?
Use propsero forwarding pointers perhaps?
[More good stuff about SoAPs and such...]
>THE MODEST SUGGESTION
>
>Of course, now the URC of a URN is far too big to download to a browser
>every time we just want to get the URL for the next resource. What do
>we do to cope with this problem? Well, we need a way to pick out the
>appropriate fields of the URC. Here is my modest suggestion. We
>extend the structure of a URN from
> <URN:opaque_string>
>to
> <URN:method[(arg_list)]:opaque_string>
This looks a lot like a prospero path:
/dirlink/dirlink/filter(arg1,arg2,arg3)/link/file
Prospero supports these nifty things called "filters" that model,
for example, archie and WAIS queries. The would probably work
nicely for this sort of thing.
Anyway... good stuff, Mr. Daniel.
Dan
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<connolly@hal.com> http://www.hal.com/%7Econnolly/index.html