Date: Fri, 18 Feb 1994 14:58:37 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9402181958.AA02654@brainy.smarts.com>
To: moore@cs.utk.edu, raisch@internet.com, M.T.Hamilton@lut.ac.uk
Subject: Re: Finding URN->URL servers
> > In the MX record, the CPU is a standard NS formatted email address for the
> > administrator, and the OS is a URL which points to an IAFA-style meta-
> > information document.
>
> If we're going to overload existing record types, better to just use TXT.
I definitely agree with Keith's statement, especially since Robert's example
overloads the meaning not just of MX records, but of HINFO (CPU and OS). The
only useful thing that MX records give you is the preference value, but it
would not be too difficult to embed that into a TXT record.
> So while it's probably okay to use DNS to *locate* a URN->URL
> server, it's probably better to have some other protocol actually
> do the lookup. (Then we don't have to try to overload record types,
> either.)
I was initially among those who felt that URN->URL lookup could be done by a
combination of DNS lookup and client-side string replacement algorithms, but I
have been gradually convinced that Keith is right about this, not just because
it reduces the DNS load, but because it simplifies and reduces the amount of
information which needs to be embedded in DNS.
This is important both politically and technically, since a URN resolution
administrator will often not be the relevant DNS administrator, so it is
desirable to minimize the possibility of conflicting DNS assignments, and
limit the need for updates to the DNS information.
However, I still have problems with Keith's suggestion of using A records
rather than TXT records:
> 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).
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. Rather, I suspect
that it will just complicate matters later on, when we want to migrate to
whois++TNG (the next generation) or whatever greater and better thing will
follow it. In any case, the "well-defined library routine (gethostbyname)"
makes no promises about using DNS, and in fact may be implemented using host
tables, NIS, NIS+ or whatever. Code for looking up TXT records can be adapted
fairly easily from existing MX lookup code, and heck, I'll even volunteer to
write a freely available function to do that, once the specification for URNs
and the TXT records describing the lookup servers has stabilized.
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:
New domain:
DNS names for URN->URL lookup services can be directly derived from
any possible URN naming scheme, since there are no potential conflicts
in naming under the new domain.
Minimum levels of lookup service support can be required before
creating entries in the new domain, improving consistency and quality
of URN lookup.
Delegation of URN namespace and DNS namespace can be coordinated. If
desired, DNS namespace could be kept centralized, although this might
cause a scalability problem when millions of people start looking up
URNs every hour.
Prevents URN naming schemes from becoming implicitly tied to DNS, and
could simplify support for other service discovery mechanisms, like
X.500.
Existing domains:
Reduces number of DNS domains to administer, since existing ones can
be used.
Streamlines delegation of namespaces, since institutions with existing
DNS delegations can start using their namespace immediately, without
waiting for political approval of the new domain (and deciding who
will administer it).
Since the URLs describing the URN->URL lookup services will typically
embed a domain name for the lookup server, it is convenient to have
the administration of this information close to the administration of
domain names for the lookup server; if the name of a server changes,
the URLs containing them will be in the same database.
Can support a new domain dedicated to URNs, just as it supports any
other domain.
My preference at this point is for using existing domains, rather than a new
URN.INT domain, especially since the last point above allows this approach to
subsume many of the advantages of the new domain approach in the long term, if
they should prove desirable, while retaining the fast deployment advantage in
the short term.
@alex