# Re: URN namespace

Michael Shapiro (mshapiro@ncsa.uiuc.edu)
Tue, 15 Aug 1995 23:32:30 -0500 (CDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Keith Moore: "Re: URN namespace"
- Previous message: Larry Masinter: "Re: Globalizing URIs"
- Next in thread: Keith Moore: "Re: URN namespace"
- Reply: Keith Moore: "Re: URN namespace"

    From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)

    Message-Id: <9508160432.AA16779@void.ncsa.uiuc.edu>

    Subject: Re: URN namespace

    To: moore@cs.utk.edu (Keith Moore)

    Date: Tue, 15 Aug 1995 23:32:30 -0500 (CDT)

    In-Reply-To: <199508160302.XAA23034@wilma.cs.utk.edu> from "Keith Moore" at Aug 15, 95 11:02:00 pm

Keith Moore wrote:
|
|> Wouldn't a separate namespace (perhaps within DNS with a new
|> toplevel domain) be a step in the right direction?
|
|Lots of variants of this (new top-level domain, new class,
|new port number) have been proposed. It's widely
|recognized that part of the problem with "stale URLs" is
|their use of conventional DNS space.
|
|But just as it's very convenient (for some) to be able to use
|existing filenames in URLs, it's also very convenient to be able
|to use ordinary DNS names in URLs: you don't have to do much
|in the way of registration to get on the web. Were we to *require*
|a separate DNS space for URNs, you'd have to go through two
|registration procedures to get a server up and running: one for
|the server host name for URLs, and another for the chunk of URN space.

I don't know what you mean by "conventional" DNS space. This is a new
term to me.

I was talking about the top level domains that exist now as being the
problem. I define "existing" DNS name space as the current top level
domains. URNs should not use this name space. They should have a
complete new top level domain. If you look at the path scheme, you'll
see that it not only supports using the existing domains (hence the
existing name space) but also any new one (meaning new top level
domains). It doesn't require it, but you'll get more persistence if
URNs use a name space that is restricted to use for URNs only. The
path scheme then maps this URN name space to existing hostnames to get
to the document servers.

For example:
path:/urn/na/sub-na/sub-na/document
would first map to
sub-na.sub-na.na.urn
The TXT records for sub-na.sub-na.na.urn would name the document servers,
using URL prefixes:
sub-na.sub-na.na.urn TXT "path-u http://hostname:port/prefix"
would map to
http://hostname:port/prefix/document

|
|There are other conveniences: given the hostname from a URL,
|it's trivial to construct an email address of someone who
|likely maintains that web server (try webmaster@[address],
|if that fails, try postmaster@[address]).

Then we add something to URNs that provides this service - lookup the
email address for the maintainter of the URN - rather than have the
user (or a program) guess.

We could do this with path by TXT "path-m webmaster$hostname"

|
|So I prefer an *additional* (rather than separate) chunk of
|DNS space, which is not structured according to organizational
|hierarchies and which is not meaningful to humans. Those who
|have a need for long-term names can use the new name space,
|while those who don't can continue to use ordinary DNS names.
|

Again, I don't know what "additional", "separate", "ordinary" mean.
You either work from the existing top level domains, or you work from
new ones. I think you are agreeing with me though. You want DNS
heirarchies that are distinct from the organizational one which we have
now.

|
|> The existing hostname is used for mail (and
|> other services). Why should email and URNs share the same name
|> space? The U.S. post office and the phone company don't share
|> the same name space.
|
|No, but this is because the phone system wasn't able to accomodate
|a rich enough name space to handle postal addresses when it was
|first deployed.

Perhaps, but this just means that they couldn't use the existing
technology and had to create a new one. Had they used the existing
address space they would have hit location-dependence really quickly.

|The phone companies also need to be able to
|assign new subscriber numbers at different times than when street
|addresses change. How many CIDRs (changes of routing hierarchy)
|and IPngs (changes of address space length) has the US phone network
|endured?
|
|Nowadays you'd also want to keep address and phone number separate for
|privacy reasons.
|
|And of course street locations and phone numbers describe
|completely different things. Both of them change fairly
|frequently relative to the people associated with them.

Here you state reasons that phone numbers needed a different name space
than postal addresses. The fact that their name space may not have
solved the routing problems does not mean they should have used postal
addresses instead.

|Neither of them seems analogous to URNs.
|

Not a strict analogy. But I still think that URNs are different than
email addresses and hence need a different name space than the
hostnames used for email.

    --
    Michael Shapiro                   mshapiro@ncsa.uiuc.edu
    NCSA                              (217) 244-6642
    605 E Springfield Ave. RM 152CAB  fax: (217) 333-5973
    Champaign, IL 61820

- Next message: Keith Moore: "Re: URN namespace"
- Previous message: Larry Masinter: "Re: Globalizing URIs"
- Next in thread: Keith Moore: "Re: URN namespace"
- Reply: Keith Moore: "Re: URN namespace"