Message-Id: <199410251949.PAA15508@postman.osf.org>
To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Subject: Re: Current URN syntax is unacceptable
In-Reply-To: Your message of "Tue, 25 Oct 1994 09:38:14 CDT."
<9410251438.AA06067@void.ncsa.uiuc.edu>
Date: Tue, 25 Oct 1994 15:48:45 -0400
From: "Norbert Leser - OSF DCE: (617)621-8715" <nl@osf.org>
Daniel,
many thanks for your thoughtful reply. Enclosed are a few questions and
comments:
> [...]
> Although I acknowledge that the updated URN requirements draft
> now qualifies the supported existing legacy naming systems
> with "insofar as they satisfy the other requirements", there
> is no good reason for imposing unnecessarily constrains that
> would prevent a number of naming systems to use the URNs.
>
> There is a good reason for constraints. To be scalable (i.e. to get
> locality of reference), there must be a public, hierarchical naming
> system. If more naming systems are allowed, there must be only a
> small fixed number of them (presumably the ones grandfathered in)
> because these must be known by clients or their proxy servers.
>
> It is possible to have an indefinite number of naming schemes only if
> they map to a small fixed number of types of naming schemes. This is
> so that the implementation of name resolution need not be changed for
> all clients and proxy servers each time someone comes up with a new
> naming scheme.
I agree. It is not my intention to pollute the namespace with a number
of registered schemes. What I have in mind is a rather small set of top
level schemes for exactly the reason that URNs are good for: They
provide persistent names (i.e, identifiers) for the objects to be located.
"dns" could be one of such top level naming authority. I'd envision "xfn"
as another one that provides the entry point to the federated naming
namespace. There might be a very few more.
> [...]
> Any registered naming authority specifies the
> encoding rules for these opaque strings. This
> includes the possible insertion of multiple and
> hierarchical sub-naming authorities, the ordering of
> multiple atomic names (in hierarchical naming
> systems, for instance), the delimiters used for
> sequences of atomic names, and other naming system
> specific properties.
>
> It is not sufficient to push the hierarchical naming down to the
> opaque string. The hierarchical part of the name must be public so
> that clients or proxy servers may cache the location of both naming
> authority servers and their ancestors. An ancestor is first asked
> where a naming authority is rather than hitting on the top level,
> single root of all naming authorities. This is essential for
> scalability. DNS does this already, so that's why the proposal takes
> advantage of it.
I see the need, but exposing a hierarchy of naming authorities creates
exactly the problem that you want to avoid, doesn't it? How can the
persistency of names be maintained if there are a large number of naming
authorities involved (no matter whether it's hierarchical or flat)?
How can it sensibly be managed if one of these authorities goes away
or if objects move to another authority over time?
Yes, hierarchies is a way of providing for scalability, but why isn't
this the property of the naming system that controls the namespace
of top level naming authorities?
DNS has one way of dealing with it but there are others as well.
XFN, for instance, provides a resolution protocol based on composite
names; it doesn't need a hierarchy of registered naming authorities.
Again, I'm sensitive to the scalability problem, but isn't solving this
persistency problem already one part of the scalability story? Another
important aspect, which we seem to agree on, is the very small manageable
number of top level authorities. Any other aspects that address scalability
such as hierarchical organization, the resolution process, caching, etc.
should be left to the naming systems involved.
> Slight diversion: I actually would prefer a more uniform scheme that
> is thoroughly hierarchical all the way down, even throughout the
> "opaque" string (or for grandfathered schemes, as far as they have
> gone). This lets a naming authority either handle its hierarchical
> name space all by itself or delegate parts of it to subauthorities as
> required by the load, and clients can then cache the locations of
> subauthorities. But the current proposal is probably sufficient
> because the number of requests for any particular document generally
> declines over time, so the name resolver associated with that document
> can safely assume it will not have to handle more requests in the
> future.
I have a very hard time believing in this concept of hierarchical
naming authorities that are exposed in the name. Isn't this pretty much
shifting the location problem of URLs just one level higher instead of
solving the real problem, namely providing a persistent name/identifier
that is independent of specific server and location information and such.
> Baring a thoroughly hierarchical scheme, I would prefer to fold all
> the naming authorities into one hierarhical scheme. This would avoid
> the need for prefixing the hierarhical part with "dns". Grandfathered
> non-hierarhical naming schemes would reside at the first level of the
> hierarchical names. E.g. URN:path.net:mitra1234 and URN:isbn:5678
I'm not sure if I really understand what you mean but this looks pretty
close to what we do with XFN (or similar with DCE naming, if you're more
familiar with that). We have the notion of a global namespace and a single
global root. At this very top level one branches into the respective
global naming system (which is currently determined, but not limited,
to be DNS or X.500). However, in order to avoid registration of scheme id
strings (i.e., top level naming authorities) we have chosen a resolution
based approach.
Norbert