Re: OCLC's URN Services Proposal

Keith Moore (moore@cs.utk.edu)
Tue, 13 Jun 1995 22:08:30 -0400


Message-Id: <199506140208.WAA17631@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: roxanab@attmail.com
Cc: uri@bunyip.com, moore@cs.utk.edu
Subject: Re: OCLC's URN Services Proposal 
In-Reply-To: Your message of "Tue, 13 Jun 1995 19:26:21 -0000."
             <9506140123.AD27984@hoccson.ho.att.com> 
Date: Tue, 13 Jun 1995 22:08:30 -0400

> As a (more or less :-) neutral party, I'm working with Ron to try to put
> together the "stone soup party" revision of the URN bakeoff. I know of
> all the URN proposals that have been discussed on the list. Is there
> anyone else out there that's working on a URN proposal that hasn't been
> announced? For that matter, is there anyone out there that's no longer 
> working on a URN proposal that has been announced :-)

Sort of.  We're working on a proposal for a gradual transition from
URLs to URNs.  The idea is to extend URLs with a new DNS record
(like an MX record) so that they're not tied to a particular machine.
Instead of talking to the HTTP (or whatever) server at the host indicated
by the domain's A record, you talk to the URN or URL lookup server at the
host indicated by the domain's URIS (URI server) record to find a list
of servers for a particular URL or URN.  This lets us get some of the 
benefits of URNs in the short term (including fault tolerance, distributed 
load, better network utilization), while building an infrastructure that 
can eventually be used by URNs.

We hope to have specs out in the next few weeks, and demos in Stockholm.
Right now we're working on getting the servers up and running.
 
> Also, in Danvers, one of the URN proposals discussed was LIFNs. However,
> as I recall, LIFNs contain meta data which led to some confusion as to
> where LIFNs fall into the URI architecture. So I will pose this to Keith,
> should LIFNs be considered in the context of URNs, URCs, or something
> else?

The central idea behind LIFNs is that you have a separation between
the intrinsic properties of a resource (i.e. the URC information)
and the properties of the locations of a resource.  LIFNs are the glue 
that tie them together.

So the set of locations of a resource isn't part of the URC
itself.  Instead, the URC contains the location-independent names
(LIFNs) of one or more realizations of that resource.  (e.g. the text 
version would have a different LIFN than the html version).  
The client/user/browser chooses which realization it wants,
then performs a lookup on that LIFN to find a nearby location from
which to access that resource.  (As an optimization, the URC server
can perform that lookup on behalf of the client for any LIFNs found
in the URC, so the client doesn't have to do multiple lookups.)

This makes a clean separation between the choice of which of
several realizations of a resource to use, and the choice of which 
location to use to access that particular realization.

Keith