Date: Tue, 25 Oct 94 09:38:14 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9410251438.AA06067@void.ncsa.uiuc.edu>
To: jcurran@nic.near.net, mitra@path.net, nl@osf.org
Subject: Re: Current URN syntax is unacceptable
From: "Norbert Leser - OSF DCE: (617)621-8715" <nl@osf.org>
>At 1:27 AM 10/23/94, Roy T. Fielding wrote:
>>The following syntax (as seen in <URL:http://www.path.net/mitra/urn.html>)
>>is unacceptable for use as a URN standard.
>>
>> URN:dns:path.net:mitra1234
>>
>>should be
>>
>> dns:/path.net/mitra1234
>>or
>> urn:/dns/path.net/mitra1234
>>
>>so as to preserve a common URI syntax, as previously agreed
>>on this forum.
This would be acceptable to me as long as we can have knowledge of
where a public, hierarchical namimg scheme is used. I.e., immediately
after "dns" is a domain name. The use of colons as separators suggests
that everything before the last colon is public, as intended.
[...]
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.
Therefore, I'd propose to limit the specification in the "Syntax"
section of the URN draft to following concepts:
- The URN consists of three parts, its URN header, a scheme
identifier, and an opaque string.
If the scheme identifier were hierarchical, this would be OK. But
that is not what you intended.
[...]
- The scheme identifier is a registered case insensitive ascii
string, identifying the top level naming authority.
[...]
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.
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.
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
But the current proposal is a reasonable compromise. I am willing to
compromise everything but for two requirements:
1. There must be a public hierarchical naming scheme.
2. There must be only a small fixed number of other schemes.
Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications