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

Keith et al,

Unfortunately, I can't be at the URN BOF (but I have now rearranged my
schedule so I will be there for the URC BOF), so I would like to have
some discussion before then to air some of my concerns about the
proposal.  I have a number of questions that generally, but not
completely, harken back to the requirements document RFC1737, that
represented consensus of the group.  If that is no longer the case,
then we had better reopen the whole thing, but I personally think that
that's a really bad idea and don't recommend it.

I should say also as a preliminary, I think we need several things,
which have been on the table since before Stockholm.  For the current
discussion and in light of the note from Keith, they fall into three
parts.  First, there is the question of a general syntax for URNs.
Second, within that there may be a variety of more specific schemes
and restrictive schemes.  These are often developed in conjunction
with a name resolution plan, which is the third issue.  Just because a
naming scheme has been developed in conjunction with a particular
resolution scheme does not mean that that resolution scheme is the
only one that might work for a name of that form.  So, a fourth issue
should be (as I suggested in my I-D for Stockholm) an architectural
feature and specification of a mechanism to allow for finding useful
resolution services of various flavors.  

I should say as an aside here that I applaud the group effort to
reduce the number of proposed URN/resolution schemes at this time.  As
a community we can't effectively support many of these, but in order
to be realistic about the past and future, we should be supporting
more than one.

So with all that said, I am left with some questions for you, Keith,
or whoever from the representing group wishes to address them.
Unfortunately as a community we do not have a real architecture
document, nor do we have requirements documents for anything other
than URNs.  But, we do have proposals for both a general syntax (to
which you have chosen not to adhere) and a variety of specific URN
schemes in conjunction with specific proposals for resolution schemes.
Your newest proposal seems not to quite meet the requirements of the
URN requirements document, clearly is slightly different from some of
the previous URN/resolution schemes, and seems not to address at all
the problems of allowing for more than one resolution scheme.  I am
left a little puzzled.

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

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.

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?

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?

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?

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.

6. As I understand it, you have fairly tightly coupled naming
authority names and resolution services.  Is it possible to have
several different resolution services providing translation for
different parts of the namespace of a naming authority?  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?  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?

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.

Received on Tuesday, 21 November 1995 15:27:19 UTC