# Re: URN Resolution Paths Considered Harmful

Karen R. Sollins (sollins@lcs.mit.edu)
Wed, 28 Jun 1995 17:01:54 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Daniel LaLiberte: "Re: URN Resolution Paths Considered Harmful"
- Previous message: Patrik Faltstrom: "Re: Metadata Bar BOF"
- In reply to: Daniel LaLiberte: "Re: URN Resolution Paths Considered Harmful"
- Next in thread: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"
- Reply: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"

    Date: Wed, 28 Jun 1995 17:01:54 -0400

    Message-Id: <199506282101.RAA09325@lysithea.lcs.mit.edu>

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

    To: liberte@ncsa.uiuc.edu

    In-Reply-To: <9506271847.AA11810@void.ncsa.uiuc.edu> (liberte@ncsa.uiuc.edu)

    Subject: Re: URN Resolution Paths Considered Harmful

Dan,

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?

Anyway, I see a slightly 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.

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. In addition, I
hope we don't choose a path that will restrict generality in the
future. 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 resoluver named by
the prefix. That resoluve 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. This
can be generalized further, but 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.

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.

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

I think you were also suggesting that although the resolver name may
be embedded in the URN it need not be used. 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.
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.)

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.

Karen

- Next message: Daniel LaLiberte: "Re: URN Resolution Paths Considered Harmful"
- Previous message: Patrik Faltstrom: "Re: Metadata Bar BOF"
- In reply to: Daniel LaLiberte: "Re: URN Resolution Paths Considered Harmful"
- Next in thread: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"
- Reply: Mark Madsen: "Re: URN Resolution Paths Considered Harmful"