# Re: UR Accessors

Keith Moore (moore@cs.utk.edu)
Wed, 14 Jun 1995 11:55:43 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rich Salz: "Re: UR Accessors"
- Previous message: roxanab@attmail.com: "Re: Question for DNS propronents?"
- In reply to: Daniel LaLiberte: "UR Accessors"
- Next in thread: Rich Salz: "Re: UR Accessors"

    Message-Id: <199506141555.LAA19466@wilma.cs.utk.edu>

    From: Keith Moore <moore@cs.utk.edu>

    To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)

    Subject: Re: UR Accessors

    In-Reply-To: Your message of "Wed, 14 Jun 1995 09:06:38 CDT."

                 <9506141406.AA07908@void.ncsa.uiuc.edu>

    Date: Wed, 14 Jun 1995 11:55:43 -0400

> 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
lifn=lifn://some.other.domain/stuff
}
realization: {
content-type: text/plain
lifn=lifn://some.domain/stuff2
}
}

location data for lifn://some.other.domain/stuff: {
location: {
URL: ftp://cs.utk.edu/books/tolkien/hobbit.ps
TTL: 30 minutes
expire-date: jul 5, 1998
}
location: {
URL: http://www.cs.utk.edu/books/tolkien/hobbit.ps
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.

Yes.
> 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.

right.
> 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.

right.

Keith

- Next message: Rich Salz: "Re: UR Accessors"
- Previous message: roxanab@attmail.com: "Re: Question for DNS propronents?"
- In reply to: Daniel LaLiberte: "UR Accessors"
- Next in thread: Rich Salz: "Re: UR Accessors"