Message-Id: <9404061620.AA00323@emmetal.cs.wisc.edu>
To: pays@faugeres.inria.fr
Subject: Re: URC's
In-Reply-To: Your message of "06 Apr 1994 05:23:32 +0200."
<765602612.24283.0-faugeres.inria.fr*@MHS>
Date: Wed, 06 Apr 1994 11:20:50 -0500
From: Bob Kummerfeld <bob@cs.wisc.edu>
In message <765602612.24283.0-faugeres.inria.fr*@MHS>, pays@faugeres.inria.fr w
rites:
> What is the meaning of the mapping service concept use by this URI group?
>
> It can only be a form of name server (eg. a directory service)
> which when submitted a name (URN) is able to return one or a more
> locators URL.
> Remember we had to use a name server to get directly or indirectly
> the characteristics. If the name/locator of the mapping service
> is found in he URC, then we have in betwee 3 to 5 access to a
> name server to get a Locator for the initial URN... Does
> that make sense? Which will be the initial name server
> in order to bootstrap the process?
>
>
>In fact very pragmatically I am convinced that we need to limit
>to something requiring
> a single directory service
> or
> at most a directory service and a location service
>
>By location service I understand something a la Archie which will
>know of the existence of specific copies/instances. However
>in this second case plenty remain to be defined for the
>spec to become "implementable".
Yes, efficiency is important and in many (most?) cases you would want to
do a simple URN->URL mapping. BUT what if I want to get more information
about the object before fetching it? The object may be a 50Megabyte MPEG movie
and I want some "citation" information (keywords etc) to help me decide if
I really want to fetch the object. In this case I want to be able to retrieve
a URC corresponding to the URN.
So, perhaps the directory could be structured to allow both URN->URL as well
as URN->URC lookups.
Bob Kummerfeld