Re: UR Accessors

> We need a new name for a URI concept that has been bouncing around
> under the name "URC0".  A URC0 has been thought of as a set of URLs
> (previously called a list of URLs) where any one of the URLs would do
> as the identifier of the resource.  

This is *exactly* what we (the LIFN folks) are doing with the separation 
between intrinsic characteristics of the resource (which we call a URC),
and the characteristics of locations of the resource (which we're calling
location data; I think this is what you are calling URC0).

> Keith Moore mentioned the distinction between intrinsic metadata and
> extrinsic access information.  (Others have made this distinction
> too.)  In their case, the access information is a list of location
> independent file names (LIFNs).  This distinction is the same concept
> I am trying to get at.  More general than a set of URLs is a set of
> URIs.

Just to be clear, I'll give a concrete example:

URC for URN://some.domain/stuff: {
title: there and back again
author: j. r. r. tolkien
realization: { 
	content-type: application/postscript
realization: {
	content-type: text/plain

location data for lifn://some.other.domain/stuff: {
location: {
	TTL: 30 minutes
	expire-date: jul 5, 1998
location: {
	TTL: 30 minutes
	expire-date: dec 15, 1995

location data for lifn://some.domain/stuff2: {

> Maybe we should call this new thing a URA, with "A" for "accessor".

Yes, we do need a name ("location data" doesn't quite ring, does it?), 
but maybe we need a name that *doesn't* start with UR :)

> When resolving a path URN in a proxy, we would like to return this
> list of sets of URIs as a package for the client resolve in whatever
> way it wants.  Either we do that or the proxy must resolve it, but
> that is a problem for a number of reasons: It interferes with client
> directed URI resolution, caching, authentication, etc.  In general,
> clients should do as much as they can to off-load servers, and to do
> things as they want to or need to.  

> Another possible solution is to soup up the protocol by which clients
> talk to proxies such that a proxy can ask the client to resolve a
> URI or a set of URIs and the client does that and tells the proxy
> whether it is satisfied or it wants another set.  This extension to
> the proxy protocol (an extended subset of HTTP?) is not a bad idea to
> consider.

Rather than soup up the client-to-proxy protocol, our proposal
has the client talking directly to the servers for URC and location
data.  You can still use a proxy, but that's the exceptional case --
for when you want to use a proxy to get past a firewall or 
when you want to use a client that doesn't support the new protocol.

The client can speak ordinary HTTP to the proxy, and it will do the 
URC/location lookup and cache management, etc., on behalf of the client.
Or the client can be told to speak the URC/location resolution
protocols with the proxy server instead of the actual servers for 
those URNs and LIFNs.
> One way or another, handling this list of sets of URIs involves
> changes to clients, either to understand the new proxy protocol, or to
> handle the list of sets of URIs itself.

> Another reason to make this list of sets of URIs into an object that
> can exist on its own rather than to treat it as just part of the
> resolution process is so that it can be cached for reuse later rather
> than recreating it each time.  

Yes.  It turns out that you want different cache rules for location
data than for the characteristcs of an object.

> Another thing to consider in the generalization of the list of sets of
> URIs is that for each URI, or each set of URIs, there could be
> additional information about cost, speed of service, and other access
> related things.  



Received on Wednesday, 14 June 1995 11:55:20 UTC