Re: Question for DNS propronents?

Keith Moore (moore@cs.utk.edu)
Fri, 16 Jun 1995 17:28:28 -0400


Message-Id: <199506162128.RAA04496@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: "Terry Allen" <terry@ora.com>
Cc: Keith Moore <moore@cs.utk.edu>, Larry Masinter <masinter@parc.xerox.com>,
Subject: Re: Question for DNS propronents? 
In-Reply-To: Your message of "Fri, 16 Jun 1995 13:48:49 PDT."
             <9506161348.ZM5235@dmg.west.ora.com> 
Date: Fri, 16 Jun 1995 17:28:28 -0400

> Keith Moore:
> | The criteria in RFC 1737 are not sufficient to produce an efficient
> | system.
> | > but so long as a URN is globally unique, any sort of lookup method
> | > will serve.  
> | But this doesn't mean that any lookup method is as good as any other.
> | URN resolution should be a low-cost service.  If we design URNs right,
> | the lookup can be cheap, at least for the common cases.  If we don't
> | pay attention to this aspect of design, it will be expensive.
> 
> Over time it will be more and more difficult to deduce from a
> URN what resolution service to send it to.  

This is true.  But the "time" you're referring to is the time since
the creation of a particular resource name.  Assuming that most of the
names one wishes to resolve are for recently created resources, it
makes sense to optimize that case.

> You may have to guess or use locally-built heuristics ("urnsrus.com
> works for us 90% of the time").

Or you may have a proxy resolver.  Or you may want to talk to the
net.equivalent of a rare/used book store.  Whatever.  It's still very
useful to have "primary" resolution services keyed to the URN.

> And DNS is not forever; new systems will arise.  

Sure enough.  But I have a great deal of faith in future engineers to
design new systems to meet their needs for their time...so long as we
don't tie their hands.  If we can put some structure in the URNs that
aids resoultion, chances are that the future engineers will be able to
deal with it.  If we don't do so, and find out later that we need it,
it'll be more difficult to put it in.

> | It's like saying you can design a transmission without considering the
> | overall characteristics of the automobile.  You might be able to hook
> | everything together, but it won't work well.
> 
> In this case the transmission is really really simple.  The engine
> hasn't been designed yet, and the driveshaft is only roughly spec'd.

Yes, but you don't design a car around the transmission and the
driveshaft.  You design a car around the two things you can't easily
change: the human user and the roads.  In this case, we need to design
a *system* (of which URNs are only a part) to accomodate the needs of
humans and the characteristics of the net.

> My point is really that it would be fruitful for the group to evaluate
> the URN proposals against the criteria in RFC 1737 to see how best to
> achieve the most important one (uniqueness) with some measure of the
> others too.

Agreed.  But once we get around to desigining the *system*, we might
find out that RFC 1737 left out a thing or two in some areas, and was
overly constraining in others.

Keith