Date: Wed, 15 Dec 1993 14:11:13 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9312151911.AA20196@brainy.smarts.com>
To: uri@bunyip.com
Subject: Re: DNS lookups for URLs (was: URN functionality from URLs)
Keith Moore <moore@cs.utk.edu> writes:
> Files should be referenced by URN (not URL). Then the DNS should be used
> to find the "official" URN->URL lookup service. If you have a local cache,
> you should consult it first to see if it has a cached copy of the file
> indicated by a particular URN.
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).
As for the local cache, how does a client find out where it is (and what
protocol to use to access it)? 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).
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).
> 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.
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?
Maybe I don't understand, but don't all URNs refer to "exact copies of bits" (modulo the representation variant issue)? In the architectures I've been discussing, getting the bits referred to by an URN is typically a two-stage process, where the URN is converted into an URL that is used to retrieve the bits. In this model, the bits can be cached "forever", since they should never change, but the intermediate URL should have some limited lifetime. Different caching mechanisms could be used for each kind of information.
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).
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.
I don't think that using TXT records is that unclean; as I mentioned above,
RFC 1383 has a nice model that seems perfectly acceptable for experimental
use. I agree that the important part is making the records usable, and using
TXT records will allow us to quickly determine how usable they are.
@alex