Re: Question for DNS propronents?

Terry Allen (terry@ora.com)
Fri, 16 Jun 1995 13:48:49 -0700


From: "Terry Allen" <terry@ora.com>
Message-Id: <9506161348.ZM5235@dmg.west.ora.com>
Date: Fri, 16 Jun 1995 13:48:49 -0700
In-Reply-To: Keith Moore <moore@cs.utk.edu>
To: Keith Moore <moore@cs.utk.edu>, "Terry Allen" <terry@ora.com>
Subject: Re: Question for DNS propronents?
Cc: Larry Masinter <masinter@parc.xerox.com>, roxanab@attmail.com,


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.  You may have to
guess or use locally-built heuristics ("urnsrus.com works for
us 90% of the time").  And DNS is not forever; new systems will
arise.  I conclude from that that you can't design URNs that 
tell you where to look them up, and that if you do, they'll cease
to work that way after awhile.

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

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.



Regards,

-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472

A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html