Date: Thu, 15 Jul 1993 18:20:46 +0100 (BST)
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Subject: Re: URNs in the DNS
To: Keith Moore <moore@cs.utk.edu>
In-Reply-To: <9307140920.AA22956@thud.cs.utk.edu>
Message-Id: <Pine.3.07.9307151702.G4919-c100000@lust>
Keith said:
> I would prefer that the DNS be used to locate a URN-to-URL
> server for a particular naming authority, but that the actual
> server not use the DNS. My understanding is that existing
> DNS servers have scaling problems. Alternatively, we could
> develop a new DNS implementation or DNS protocol extensions,
> but that would take longer.
In my mind there are many potential solutions to the URN->URL
lookup problem, and the associated metadata directory one, and
I don't think it's terribly wise to progress to the RFC level
without a bake-off - even if it's only on 'paper' :-)
Sure there are problems with placing URNs in the DNS, but there
are also problems with most of the other schemes. With this
in mind, I should say that one of my motivations in making this
suggestion was in hoping to stir up some debate on the subject!
My main concern is that the DNS might break under the load of
all these URLs and URNs it had to remember, so if there are any
takers, perhaps we can arrange some experiments (also to discover
the limitations or otherwise of the vendors' implementations!).
On a related note, I've been trying to piece together my
thoughts on the whole issue (see below) and would welcome
any feedback you choose to give...
For the whole thing to work, it must be possible to approach
at something like this level:
1. Given a URL I can use it to access the networked object
2. Given a URN I can get some URLs for it and choose the
most appropriate one for me somehow
3. Somehow I can find out the URNs for the information I'm
interested in
We're OK on 1, I think. Whether 2 should exist separately from
3 is problematic. It seems reasonable to expect that 3 will
not be the only source of URNs, just as we're seeing URLs
popping up in .sigs these days, and there will probably be large
numbers of both cropping up in printed material if the idea
catches on.
A couple of crucial aspects are certainly
a) how well the mechanism will cope as the size of the
information base grows - in particular how long will
it take to convert a URN to URLs ?
b) how long it will take to get a reference implementation
of 3 widely distributed & in use ?
Even better - who's to say what sort of metadata is appropriate
for a given object? Let's pretend I've got some pictures of rock
samples, collected in the Sierra Nevada (I can give you the
position down to the nearest centimetre if you like :-). Oh, and
they're carbon dated to three million years old, by the way...
Or to put it another way, I think the metadata aspect is so
interesting (intractable?) that it could be quite a while before
everyone has had their say! On the other hand, URNs and URLs
are sufficiently concrete that there may be something to be gained
from getting them into production use straight away.
So, just for fun, here's the alternatives for the URN->URL problem
as far as I can see:
1. Store metadata & URN->URL mappings together
- new technology, e.g. Registrar (+ DNS to find servers?)
- existing technology, e.g. X.500, DNS
2. Store metadata in the URN or URL
- new technology, e.g. URMs
3. Just record URN->URL mappings, no metadata
- new technology, a URN->URL resolver (unproposed)
- existing technology, e.g. DNS, X.500
Anybody have anything to add to this, or have I got a good
snapshot here?
Martin