Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

On Nov 21,  3:27pm, Karen R. Sollins wrote:

> 1. You have chosen to omit any sort of scheme name from the URN
> syntax.  Why?

Actually, it is there but it is hidden. We suggest the creation of
the URN top-level domain. New (or old) naming schemes would, in order
to claim to be URNs, register under the URN TLD. Then, when we come
across a novel naming scheme, we have a place to go to ask
questions about the naming scheme.

> 
> 2. If the NA is simply a transformation of a domain name, why have you
> chosen a different syntax for it than a domain name?  I'm against
> chosing different syntaxes for things unless there is a good reason.

Mostly this was so we would have a smooth hierarchy. This would allow
path-style floating location of resolvers if we decide that is a good
thing, and I think there is still a case that can be made for
ease of use to people who are internet novices. However, I am not
going to draw some line in the sand about that particular syntax.
We could flip the whole thing around like a CID for all I care.


> 3. As I understand it there will potentially be naming authorities for
> each domain name in the DNS.  Since these are frequently reassigned,
> how do you propose to guarantee that DNS domain names are not reused
> in this specific context?

We cannot gurantee this in the existing domains unless they already
have such a policy (I am told that some do have such a policy). This
is another reason why we propose the new top-level domain where such
a policy can be applied from the outset.

However, if we do not allow people to use their existing domain
names as a naming authority, we get into a whole slew of problems
trying to establish such a capability - 99% of which already
exists.

> 4. The scheme as it stands makes no provision for legacy naming
> schemes (or other naming schemes than yours) in the general syntax
> suggested.  How do you propose to handle this?

This is the URN TLD again. To accomodate, for example, ISBNs, someone
establishes the isbn.urn domain, and provides the new resource
records that point to a bunch of different resolvers. The rest of
the name is the opaque string, ala
  urn:urn/isbn:0-19-853737-9


> 5. You propose that a new top level domain called "urn" should be
> created.  That's fine.  The only way I can imagine handling the
> alternative naming scheme problem of question 3 is to make each other
> naming scheme besides yours be a second level name within the "urn"
> top level.  Do you consider this a reasonable approach?

Not clear on what you mean here Karen. We do NOT propose shadows of
.com, .edu, .... in the URN space. We do propose that naming schemes
claiming to be URNs register under the URN TLD. Depending on the
naming scheme, naming authorities may become third, fourth, ...
level domains, or all that stuff may be buried in the opaque string
ala ISBNs.


> Comment: If you do, I'm not sure I agree because it would somehow make
> your scheme special with respect to all others, and I'm not sure why
> that should be the case.  I'd much prefer to see them all on an equal
> footing.

Yeah, I can certainly see your point. However, to say that things
are "URNs" implies that there is some
sort of overarching namespace. We are just saying that the
overarching namespace is the URN TLD - and we also make the obvious
shortcut of allowing existing TLDs to be used as well.


> 6. As I understand it, you have fairly tightly coupled naming
> authority names and resolution services.

A naming authority, which is a domain name, can have a set of
NAPTR records associated with it. Those records would then
point to particular servers that can do resolution of names under
that authority. The records will contain the hostname, protocol,
port, and priority. So, there is a level of indirection from the
naming authority to the resolution server.

>  Is it possible to have
> several different resolution services providing translation for
> different parts of the namespace of a naming authority?

This sounds basically like the path-style multiple resolvers thing.
Another interpretation would be for the NAPTR records to contain
regexps, only those records whose regexps matched the URN would
be considered as candidate resolvers. Which of these (or both)
do you mean?

>  Over time,
> this may degenerate as the management of these resources diverges, so
> that each object named within a naming authority may be resolved by a
> different resolution service.  Is there a way to handle this worst
> case scenario?

First of all, inferring the location of a resolver based on the
naming authority is not the only way resolution can proceed. I fully
expect clients to first of all try some local resolver service, then
to try some commercial resolver service, and only attempt this
inference when that fails. Second, I think that management will
typically be over collections rather than individual documents.
Those provisos out of the way, it is still the case that we need
to consider the worst case you are pointing out.

Its a nasty worst case. It puts a resource record per
document into DNS, which is exactly what we do not want to do.
I had not considered this up to now. My quick reaction is
that the key to handling this worst case without ludicrous
explosion of resource records is twofold. The first is to require
the agency with authority over the domain name not to register
huge numbers of resolvers that only deal with tiny portions of the
namespace. The second is making sure that the URN resolution software
has the ability to forward resolution requests to a "sibling" that
has picked up part of the namespace, and the servers have some
facilites for keeping track of siblings.

>  The problem is that for each object, the question of
> which resolution service to use for it is (or should be, I believe) a
> characteristic of the object not of the namespace from which it
> happened to get a globally unique name.  Did you intend to couple
> these as tightly as you did and if so, why and how can I get around
> it?

Um, this seems a chicken and egg problem. You say that the
resolution service to use should be a characteristic of the
object, not the name. However, resolution is the process of mapping
a name to an object (or to a means of fetching the object). At the
start of the resolution process all we have is the name, not the object.
Therefore it seems hard to know characteristics of the object
rather than characteristics of the name.


> 7. Do you have any thoughts about how you would handle urns that are
> created from within some other scheme?  I suggest that perhaps there
> should be something outside any particular scheme that helps with
> this, but that each resolution scheme, when handed a name that it
> cannot translate should be prepared to either say so, or invoke this
> alternative mechanism.

Yeah, that's the URN TLD again.



-- 
Ron Daniel Jr.                email: rdaniel@acl.lanl.gov
Advanced Computing Lab        voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011      fax: (505) 665-4939
Los Alamos National Lab        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    tautology: "Conformity is very popular"

Received on Tuesday, 21 November 1995 18:05:24 UTC