Re: URN Resolution Paths Considered Harmful

Karen,

You wrote to Dan LaLiberte as follows:

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

A given resolution service may choose to offer a variety of
interfaces.  Does one insist that each of them have a unique permanent
name, does one name the resolution service and enquire for interfaces,
does one enquire of a resolution trader which then passes the
interface reference of an appropriate resolution service...?

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

Another objection is that it interferes with the freedom of others to
set up alternative resolution services (unless the embedded name
resolution service is ignored, in which case why is it in there at
all?)

I can visualise a world in which the resolution of URNs is performed
by commercial services competing on the basis of speed, breadth of
choice ("we return an average of 7.6 URCs per URN, over 3 more than
our nearest competitor!"), and a lot f other things that I'm not able
to predict.  People who have ISPs now will also have subscriptions to
RSPs (Resolution Service Providers).

<snip>

> 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 may work, but is it good?  Like you, I don't think so.

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

So if one is eventually going to have to live with indirection, why
not accept it as an advantage?  Don't build descriptions of resolution
mechanisms into URNs, require URNs to be resolvable in principle, and
allow everyone to resolve them as they wish: asking their RSP, using a
(CORBA-type?) trading service, phoning their mother, whatever.

> There may be a different way of handling each and every URN that was
> originally handled by a single resolution service.

Exactly.

> 			Karen

Regards,
         Mark.
--
________________________________________________________________________
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779

Received on Thursday, 29 June 1995 05:00:32 UTC