Date: Wed, 20 Apr 1994 11:10:53 -700 (PST)
From: Mitra <mitra@pandora.sf.ca.us>
Subject: Re: Re urn2urc-00
In-Reply-To: <199404201747.LAA13061@idaknow.acl.lanl.gov>
Message-Id: <Pine.3.89.9404201059.A23304-0100000@pandora.sf.ca.us>
On Wed, 20 Apr 1994 rdaniel@acl.lanl.gov wrote:
> Mitra (mitra@pandora.sf.ca.us) wrote:
> >Terry Allen (terry@ora.com) wrote:
>
> Both approaches are useful. Mitra's scenario talks about finding
> locations once you know the name of a particular resource. The
> name will typically be known because it is in a hyperlink.
> Terry seems to be thinking of a resource discovery scenario.
> Imagine connecting to a large URI server and doing queries against
> all the URCs to find ones that contain particular keywords, authors,
> etc.
I dont know what Terry is thinking about - but I have tried to consider
both scenarios - although a resource discovery scenario certainly needs
more explanation than I gave it. The way I see it, people will sue a
number of different resource discovery systems - WAIS, Archie, Veronica and
others we dont know about yet. These will hopefully - but not
neccessarily - allow you to search against the entire URC, and will
either return the parts of the URC they know about, or just the URNs.
Either way the client now has a URN that they can use to get
more of the URC including other URLs.
> It appears that a query mechanism, such as that in whois++, can
> easily handle the cases of URN->URL and URN->URC once the server
> has been located. It can also handle URL->URC (and probably
> URL->URN), but easily locating a server that knows of the URL does
> not seem possible with the mapping of publisher to domain name in
> Mitra's scenario.
Correct - if you only have a URL there is no deterministic way of knowing
where to get the URN, until and unless retrieval systems start allowing
you to ask for the URN. (e.g. go to a gopher and say I have this gopher
URL, tell me what the URN is). I dont see a way to solve this, because
the URL doesnt contain enough information.
> The operations Terry seems to be thinking of, URC->UR[N,L], seem
> straightforward if all the URCs for a resource are identical, which
> is implied by Mitra's scenario. (Mitra, please correct me if I am
> wrong about this implication).
I dont think I've implied that every URC is identical, because I dont specify
what information goes in a URC - I think is a collection of a URN, zero
or more URLs and meta information associated with the URN or URLs. A URC
is probably going to change over time, and I see no reason why some
service shouldnt contain pointers to critiques etc as part of the
meta-information. Note, that in my scenario I point out that a client can
use the DNS to find *one or more* URN->URC servers, not *all* URN->URC
servers. There will be other resource discovery servers which wont be
referencd as authoritive servers, but will contain URCs.
> If URCs are distributed, obtaining URNs, URLs, and other URC
> fragments once you have a single URC fragment will not be so
> easy. I would assume that each URC fragment has the URN in it, but
> it will not have a full list of URLs and other URC fragments.
This is what I'm worried about - if a client cannot resolve the URL in
of the order of a second, then its going to be unusable for menus and
things like that. I'm very worried about any kind of distributed scheme
where a single object is an amorphous collection of scraps of information
on different servers. We have enough reliability problems (7-10% failure
rate for typical cases) even with retrieving from single servers over the
internet.
> I am trying to come up with an architecture for a distributed
> URC system, but don't yet have anything I am satisfied with.
> Other people who want distributed URCs - lets talk to see where
> we are.
Please consider how to build such an architecture, so that a client
doesnt need to go to multiple servers in order to do a resolution - but
has the option of doing so if it wants more comprehensive information.
- Mitra