Message-Id: <199402211914.OAA01981@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: dupuy@smarts.com (Alexander Dupuy)
Subject: Re: Finding URN->URL servers
In-Reply-To: Your message of "Fri, 18 Feb 1994 14:58:37 +0500."
<9402181958.AA02654@brainy.smarts.com>
Date: Mon, 21 Feb 1994 14:14:06 -0500
> > Why don't we just use whois++ for this purpose? Then we can just
> > register a URN.ORG root and use ordinary A records:
> >
> > underground.URN.ORG IN A server1.underground.com
> > IN A server2.underground.com
> > IN A server3.underground.com
> >
> > would say, to look up a URN of the form URN:::::::underground:something,
> > talk to the whois++ server on that machine, and ask it for some
> > locations for that particular URN.
> >
> > This would let clients use a well-defined library routine (gethostbyname)
> > instead of writing additional code.
>
> First, the syntax of these A records is incorrect. The type for A records
> is an internet address, not a domain name, so you would specify
> 123.45.67.89 or whatever, rather than server1.underground.com. This is a
> problem, since whenever you change the address of server1.underground.com,
> the URN lookup records will need to be changed as well (and the changes
> will need to be coordinated).
You're right of course. By now I'm pretty much convinced that TXT records
are the way to go after all.
> Secondly, whatever advantages whois++ may have, it is not yet widely
> deployed, so I'm not sure that special casing whois++ lookups versus http
> or gopher lookups will significantly accelerate acceptance of URNs.
Even though whois++ isn't widely deployed, it *is* a database query language,
rather than a file access protocol. You could get http or gopher or even ftp
to do the job, but I'd rather have a URN lookup protocol that isn't tied to
any of the competing file access schemes.
The point here is that we don't need to spend a lot of time developing yet
another database query protocol if there's something "off the shelf" that we
can use.
> The third issue is a more general one; the question of whether URN->URL
> lookup services should be embedded in DNS under a new domain
> (e.g. URN.INT) or distributed within the existing domain tree. There
> are some technical and political tradeoffs here:
I suggested a new domain precisely because the current DNS is too "fat" at
some points in the tree (think of how many second-level domains are listed
under ".com", for example). This is causing problems with zone transfers.
(The "right" way to do this would be to add another class. But this would
have to wait until existing DNS servers could be replaced, and we don't want
to wait that long.)
Keith