Re: URN Resolution Paths Considered Harmful

Karen R. Sollins writes:
 > Mark,
 > 
 > Let me add to your list of reasons that it is a bad idea for a
 > resolver name (or resolution service name) to be embedded in a URN.
 > There may well be (hopefully will be) more than one resolution service
 > available at any given time.  At any particular time (T) different
 > clients may prefer different such services for a variety of reasons
 > (correctness vs. cost, for example).  How can the name generator
 > possibly know the single "right" answer the resolution service to use
 > for all time, when at any given time more than one may be the right
 > answers for different clients?
 > 
 > 			Karen

I disagree, but I believe there is a misunderstanding here.  I agree
that it would be a mistake to tie a URN to a particular resolution
service because that particular service may not exist in the future.
However, I don't think anyone is suggesting that.  

The *name* of a resolution service is not the same thing as the
resolution service itself.  The *name* of the service can be resolved,
just as URNs themselves are, by a resolution service or by a static
lookup specified by the preferences of the user.  Once you have
determined which resolution service to use, you then resolve the URN
with that service.

The path scheme, in particular, uses DNS to find resolution services
by climbing down the DNS tree from some root.  Each step of the
resolution process leads to another resolution service until you get
to the bottom.  BTW, gethostbyname does this too for resolving a
domain name that is a hostname into an IP address.  Which domains
are resolved by which DNS servers may change, but the resolution
algorithm stays the same.

Furthermore, path URN could be resolved by a completely different
process, such as by the handle service, just as any URN could be.  The
name remains the same, it is globally unique, etc.  The fact that the
names of resolution services are embedded in the path URN does not
preclude that the actual resolution service that is used may be
completely different and unknown at the time of the creation of the
URN.

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

Received on Tuesday, 27 June 1995 14:53:07 UTC