# Re: URN Resolution Paths Considered Harmful

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Thu, 29 Jun 95 01:47:06 CDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"
- Previous message: Karen R. Sollins: "Re: URN Resolution Paths Considered Harmful"
- Maybe in reply to: Fisher Mark: "URN Resolution Paths Considered Harmful"
- Next in thread: Jim Conklin: "Re: URN Resolution Paths Considered Harmful"

    Date: Thu, 29 Jun 95 01:47:06 CDT

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

    Message-Id: <9506290647.AA03043@void.ncsa.uiuc.edu>

    To: sollins@lcs.mit.edu

    Subject: Re: URN Resolution Paths Considered Harmful

Thank for the involved response, Karen. Just what I need to stay awake
at 1am.

From: "Karen R. Sollins" <sollins@lcs.mit.edu>

You're right - I was mapping name of resolution service to resolution
service. Since I tend to think in an object-oriented world, a "name"
(think URN) for a resolution service will always name the same
service, although it may move around (to my way of thinking, unless
the names for resolution services are not long-lived, globally unique,
etc.) Did you have some other naming scheme (namespace and resolution
mechanism) in mind?

Yes, the name of a resolution service in a URN ought to behave much like
a URN itself. The intention for the path scheme is that the name of
a resolution service always maps to *logically* the same resolution
service in terms of its behavior, but it may be a completely different
service, or it may be absorbed by a service higher up in the path name
space never to be seen again.

The distinction is analgous to a function that computes factorial versus
one that looks up the results in a table. They achieve the same effect
in completely different ways.

Anyway, I see a slight variation on the problem still. Once a set
of URNs have the name of a particular name resolution service embedded
in them, that group of URNs will always be tied to the same resolution
service as each other. I'm reluctant for us to choose a path where
that kind of assumption about service in the unknown future is
restricted.

This is true for the path scheme as described in the current internet draft.
We have since then extended it with a fallback mechanism such that if
the original resolution service (or its logical equivalent) does not want
to deal at all with the resolution of some set of URNs, the client can
effectively go back to higher-level resolvers. (Details forthcoming.)
The top-level resolver will therefore accumulate older but still
valuable URNs - something like the handle server would be good at this
level.

I agree with what I expect is an underlying motivation here to be able
easily to find a reliable, or just good, but most preferably
authoritative resolution service to resolve a URN.

Another important motivation is to allow the resolution of names to
happen close to where the named resource lives, at least initially.
It is better to put both under the same administrative unit if
possible, since that will put the motivation for continuing to resolve
the name in the right place. We also, of course, deal with what happens
when the named resource moves.

In addition, I hope we don't choose a path that will restrict
generality in the future.

Generality is my motivation as well. That's why I am reluctant to impose
any unnecessary semantics on URN resolution protocols. But that is another
subject.

In fact, a generalization of the path scheme has some
interesting features. The path scheme takes a long string composed of
potential substrings. It divides the string into a prefix substring
and the remainder and hands the remainder to the resolver named by
the prefix. That resolver eithers decides that it can resolve the
remainder or it strips a new prefix to use as the name for the next
resolver to which will be handed the new remainder. And so on.

All correct. The new version is a little different, but this is close
enough for the purposes of your argument.

This can be generalized further, by allowing each resolver to map
the remainder either to a location or to a pair consisting of a
resolver and string that aren't necessarily simply substrings of the
string it was handed.

So for example assume the resolver for the B component of
path:/A/B/C/D/doc.html is given the remainder "C/D/doc.html". B chooses
the next resolver in whatever way it desires and also computes some
string for that resolver. In general, this turns out to be just
a sequence of arbitrary redirects which must be followed to discover
what each subsequent resolver will do. It is powerful, but time consuming.

One of the strong motivations of the path scheme is to allow locality of
reference for scalability, so that if a client (or caches near the
client) already knows where the resolver for, say, /A/B/C is, it can go
there directly. A sequence of redirects does not allow direct access.

This helps address the problem that I was suggesting above. If two
URNs have the same resolver name embedded in them, when that resolver
goes out of business and the URNs that would have gone to it now go to
a variety of other services, as long as something knows about that
dispersement, that something can be put in place of the original
resolver service, causing the subsequent strings to be rewritten to
reflect the new state of affairs.

That is also the essense of the fallback mechanism I mentioned above.
The something that knows about the dispersement would be a higher level
resolver, or the root if none other.

This is a scheme that at least works, but it leads to permanent
inefficiencies because URNs cannot change; they are immutable, so all
the URNs with that particular resolution service name will always be
an indirection, once the original has gone out of business and its
business dispersed.

Correct, as I also argued above. It's thoughts like these that make me
think that we need to encourage indefinite retirement of old names to
be eventually replaced by new, more direct names. The old names would
continue to work but resolution of them would be slower than for the
new names.

The bottom line problem here is that the dispersion may not be
algorithmic in the URN, but rather on some other basis that isn't
known at the time of resolution (and may both be different for
different sets of resources and may change with time). There may be
a different way of handling each and every URN that was originally
handled by a single resolution service.

This problem would seem to be true no matter what the URN scheme.
Can you think of a scheme that avoids this problem? Does the solution
involve having *no* resolution service name in a URN? What's left is
only an opaque string - who will resolve it? If there are N possible
resolution services out there, do we try each of them? How large does
N have to be to handle the load? Is this essentially the handle service?

I think you were also suggesting that although the resolver name may
be embedded in the URN it need not be used.

Yes, this is a fallback mechanism completly external to the particular
URN scheme in which the client chooses some promising resolution service(s).
Consider again that a path URN might be resolved by a handle service which
just hashes the whole string and looks up whatever info is associated with
it.

Karen, I thought in our last discussion that you were arguing that
it is essential to support such external fallback mechanisms, and
therefore we need to know in advance that a URI is a name that lives
forever, so we know that it is legitimate to attempt to resolve it
in whatever way we may choose.

The problem here is that
if is there, I suspect that users (applications, clients, whatever)
will come to depend and expect from early on that the resolution
service name must be correct. This is more a matter of human nature
forcing us in a direction that has significant drawbacks but apparent
short-term payoffs. I think that we as the designers of the scheme
need to be careful to be as visionary and long-sighted as possible.

Absolutely. But I disagree that there is a problem simply because URNs
might have historical resolver names embedded in them. People, or software,
will learn to ignore irrelevant details.

We won't catch all the pitfalls, but we should try our best to avoid
those we know about. (That's part of what makes the process
challenging and often drawn out as more and more issues come to mind.)

Yes, each new twist is like the next bend in the river.

Anyway, to make a long story shorter, I agree with the desire to make
this stuff efficient, but I believe that we shouldn't pay too heavy a
price for that and should understand what the price is.

Agreed.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

- Next message: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"
- Previous message: Karen R. Sollins: "Re: URN Resolution Paths Considered Harmful"
- Maybe in reply to: Fisher Mark: "URN Resolution Paths Considered Harmful"
- Next in thread: Jim Conklin: "Re: URN Resolution Paths Considered Harmful"