Message-Id: <199312152332.SAA07280@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: dupuy@smarts.com (Alexander Dupuy)
Subject: Re: DNS lookups for URLs (was: URN functionality from URLs)
In-Reply-To: Your message of "Wed, 15 Dec 1993 14:11:13 +0500."
<9312151911.AA20196@brainy.smarts.com>
Date: Wed, 15 Dec 1993 18:32:44 -0500
> Why do we need to have a separate URN->URL lookup service? If we are
> already going to DNS to find the host to ask, why not just have the DNS
> give us the necessary information to convert the URN into an URL
> ourselves? (This does require most of the assumptions made in Terry's
> original STANF proposal).
Using DNS to locate a URN->URL server isn't stretching the existing
DNS service very far.
Using DNS to perform URN->whatever lookup is.
In particular, existing DNS servers aren't set up to be easily maintainable.
To use DNS for URN->URL lookup, we would likely end up writing special
servers that speak the DNS protocol but could also be easily updated as file
locations change. Then the roots of the URN->whatever server sub-tree
would be indicated by NS records in the regular DNS tree (pointing to those
servers).
And there are still problems with this approach, because (so I'm told)
many DNS servers don't properly cache RRs that they don't understand.
I don't think we could reasonably incorporate an URN->whatever lookup
service within DNS without defining new RRs.
Finally, the whole internet depends on DNS. The last thing the net needs is
a bunch of new DNS implementations that don't quite work right. As long as
we are going to need new "special" DNS servers anyway, might as well make
them something besides DNS, rather than make the Internet's domain name
lookup service depend on the stability of the new code.
> As for the local cache, how does a client find out where it is (and what
> protocol to use to access it)?
Local configuration matter. An X resource or a dot-file or whatever. A
LAN-based service location protocol. Maybe you could have the convention
that looking up local-urn-server.your.default.domain in the DNS would point
you to a local cache server if there were one. (But not DNS search paths!)
> And in order to check to see if a
> particular URN is present in the cache, either the client has to know
> how to convert the URN into a local access name (effectively, an URL)
> or the cache has to provide a special protocol which does URN->URL
> mapping (or perhaps just returns the data associated with an URN).
The cache would be able to perform URN->URL mappings. It should
speak the same URN->URL protocol as the "official" URN->URL servers.
> My feeling is that the best way to implement local caching is for the
> URN->URL lookup to return an URL that references a local
> {HTTP,gopher,etc.} server which will return the information from
> a cache, if present, or get a copy from the original URL, put it
> in the cache, and return that (just as, apparently the CERN HTTP
> server can already do).
I wouldn't want this behavior if the object being fetched were large and the
bandwidth between the client and the local cache were small. Maybe if it
takes too long to get the object, the local cache says "sorry, I don't have
this" but makes note of the fact that someone asked for it, and grabs it
asychronously for the next time someone wants it. At any rate, I think
different sites will want different policies for what gets cached locally.
> > We should probably just use TXT records and put URN->URL mappings in a
> > different class or top-level domain.
>
> We probably don't need another class or top-level domain (both of
> which create administrative problems). RFC 1383 uses a simple encoding
> of information in ordinary TXT records that should be more than
> sufficient for the needs of IX.
> RFC 1464 suggests a more elaborate encoding for TXT records that could be
> used, although I don't think it is necessary.
I suggested a different class or top-level domain to address concerns
about the DNS scaling problem. Encoding things in TXT records solves
a different problem.
> Larry Masinter <masinter@parc.xerox.com> writes:
> > Currently, we have the situation where some URNs refer to things that
> > are cachable (they refer to exact copies of bits) and other are not
> > (they refer to locations that are themselves updatable).
> >
> > Please please try to separate these out when you're making proposals.
> > Would you put the updatable resources in the cache?
It's a bit more complicated than that.
a) You can cache the URN->URL mappings (perhaps including other "instance
specific" information also, like how much it costs to access the object from
a particular location) so you don't have to do the URN->URL lookup again.
b) For some objects (like simple files that never change) you can cache the
URN->object mapping...e.g. if I have a URN for version 2.0 of mosaic for a
DecStation, I can remember the URN->object mapping.
c) Finally, you may be able to cache the relationship between a URN and other
information that isn't specific to a particular instance of an object, like
the title, author, etc.
Each of these is useful.
> Tim Berners-Lee <timbl@www3.cern.ch> writes:
> > The / (unlike .) currently has a significance of hierarchy
> > which allows relative URIs which some find useful.
>
> While I can see the utility of relative URLs, I think that having relative
> URNs is probably a bad idea, since moving a URN from one place to another
> may invalidate the URN, which is never supposed to happen (unlike URLs).
I don't see the utility of relative URNs either. URNs will let you move sets
of documents around that reference each other. Is it really important to be
able to have a URN behave differently depending on where you got the URN from?
This violates the assumption that URNs mean the same thing everywhere.
> Josh Osborne <stripes@uunet.uu.net> writes:
> > I think it's more important that the records be used then having BIND
> > support them instantly. It's not that hard to get a new record type into
> > BIND, it's harder to get them used. Focus on making the records useable,
> > make a sample set of patches. Don't just wack text records unless it's
> _really_ a clean fit.
It's going to be very hard to get enough versions of BIND upgraded to
make the new records useful. I expect it would take several years
for this to happen. How many users would install mosaic if they had
to upgrade their BIND implementation to make it work?
TXT records are fine w/ me as long as we don't try to overload DNS itself to
do the URN->whatever lookup. But A or CNAME records would probably work
just fine as well.
Keith Moore