# Re: Finding URN->URL servers

Alexander Dupuy (dupuy@smarts.com)
Mon, 21 Feb 1994 16:02:37 +0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Keith Moore: "Re: Finding URN->URL servers"
- Previous message: Keith Moore: "Re: Finding URN->URL servers"
- Maybe in reply to: Martin Hamilton: "Finding URN->URL servers"
- Next in thread: Keith Moore: "Re: Finding URN->URL servers"
- Reply: Keith Moore: "Re: Finding URN->URL servers"
- Reply: Martin Hamilton: "Re: Finding URN->URL servers"

    Date: Mon, 21 Feb 1994 16:02:37 +0500

    From: dupuy@smarts.com (Alexander Dupuy)

    Message-Id: <9402212102.AA11688@brainy.smarts.com>

    To: moore@cs.utk.edu

    Subject: Re: Finding URN->URL servers

> 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.

This is a very good point, which I overlooked. However, it's not clear to me
that a new URN domain would be immune to the problem of "fat" domains. In the
case of existing domains, there are techniques which can be used to break up
the fat domains (the .US domain is a good example of this - see RFC 1480).
I'm not sure if we yet have techniques to break down URN domains in a similar
way (I hope nobody will suggest that we break down URN domains by geographical
region - they *are* supposed to be location-independent! :-)

To take the current favorite example, ISBNs, you have a two-level delegation
space (by country and publisher id). If we were to create an .0.ISBN.URN.INT
domain, I suspect that it would make the current .COM domain look rather
svelte. Of course, we could split the ISBNs digit by digit, and reverse them,
in the same way the telephone number address space is mapped into the .TPC.INT
domain, but recognizing that 64.5.7.1.7.3.9.0.ISBN.URN.INT is the domain name
for the ISBN 0-937175-64-1 (Programming perl) is not very intuitive.

This is a somewhat contrived example, since I think we all agree that just
translating ISBNs into URNs is not what URNs are supposed to be about; we want
to build something much better and more flexible. But I hope it makes the
point that we will not automatically avoid the problems of the existing DNS
domain structure by simply creating a new tree. In any case, having URNs live
under existing domains or in a new domain won't make the problem of the
existing fat domains any worse or any better; the new TXT records will be at
least one or more levels below the current top-level domains in either case.

Of course, we may eventually want to support ISBNs via DNS, in which case my
proposal for ISBN.URN.INT, as ugly as it is, may be preferable to the
alternative of little ISBN subdomains all over (e.g. 64.937515.ISBN.ORA.COM)
or the alternative of just one domain level (e.g. 64.937515.0.ISBN.URN.INT).
But this is a case where we have to deal with an existing namespace, so ugly
solutions may be the best we can do. I hope we could do better for the bulk
of new URNs.

@alex

- Next message: Keith Moore: "Re: Finding URN->URL servers"
- Previous message: Keith Moore: "Re: Finding URN->URL servers"
- Maybe in reply to: Martin Hamilton: "Finding URN->URL servers"
- Next in thread: Keith Moore: "Re: Finding URN->URL servers"
- Reply: Keith Moore: "Re: Finding URN->URL servers"
- Reply: Martin Hamilton: "Re: Finding URN->URL servers"