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.

About RFC 1737:

Sometimes people will support concensus on an informational document
precisely because it is not cast in stone, and making something
informational allows for the possibility of additional refinement
before making it a standard.

As long as we don't have deployment or documents on the standards
track, and as we identify new requirements or reach a better
understanding of the implications of previously assumed approaches, we
should be free to change things.

Having said that, I find nothing in the UTK meeting attendees'
proposal that strongly violates the requirements in RFC 1737.

Moreover, there are considerations not stated in RFC 1737 which should
nevertheless influence design of URNs.  For instance, nowhere in RFC
1737 is a requirement that assignment of URNs be limited to wealthy
companies, but I suspect most of us would agree that this should not
be the case.

> 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.

Okay, as a response to your preliminary:

While we clearly need to be able to grandfather other naming systems
into URNs, this does not imply that we need an explicit field for a
naming "scheme" within URNs.  Schemes in URNs may even be undesirable.
In particular:

We certainly do not want to bind a resolution protocol with a naming
scheme, because in the long term, some of those protocols will fall
into disuse.  This is true even if the resolution protocol is only
strongly associated with a "scheme": If it turns out that clients
assume a particular resolution protocol when resolving URNs that use a
particular scheme, those clients will not be able to access those URNs
if the resolution methods change.

(Essentially, exposing the "scheme" in the name may degrade long-term
persistence of the name in much the same way as using an ordinary
Internet domain name or a filename as part of a name degrades
long-term persistence -- if doing so encourages clients to make
assumptions about the name that are not likely to be valid in the long
term.)

We therefore need to put the binding between a URN and its resolution
protocol somewhere besides the URN -- in a network-accessible registry
that can accept *any* URN and return a list of services, service
locations, etc., that are valid for that URN.

For reasons too numerous to mention here, there can and will be
multiple registries.  But if any registry can potentially return
pointers to services for any URN, the client need only be configured
with a list of *registries* to consult, rather than a (more
complicated and more frequently changing) list of mappings from URN
"schemes" to resolution services.  

With the introduction of registries, a single URN can be listed in
multiple registries and supported by multiple resolution services --
which not only allows transitions, but also facilitates convergence on
a smaller number of registry and resolution protocols.

For the sake of fairness, it's very important that there be at least
one registry that *anyone* can use to define resolution services for
their own URNs.  Today the obvious way to do this is via DNS.  Ten
years from now the "default registry" may be different, but one hopes
that even ten years from now it will still be possible for anyone to
publish things with URNs at very low cost.  This implies a widely
deployed and accessible directory service with maintenance performed
by the suppliers -- like DNS.

(To clarify the UTK report, the DNS-based URN registry was never
intended to be the only URN registry -- just a registry that anybody
could use.)

As for support of other schemes: Existing naming schemes can be
incorporated into URN-space by creating a .URN domain name for the
scheme name.  With respect to the DNS-based URN registry, services for
names from existing naming schemes can be associated with various
schemes by adding and the appropriate DNS resource records for the
.URN domain name created for that scheme.

Now, having said all of that, I'm not adamantly opposed to having
a separate "scheme" field in URNs, as long as:

1. "scheme" doesn't imply "resolution protocol", either in theory or
   in anticipated practice

2. we define a DNS-based registry that can potentially accept *any*
   kind of URN (not just those of a "dns" scheme)

3. anybody can easily register a name in the DNS registry.

I think this addresses the four issues you mention, though perhaps not
in the same order.  :)


> 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?

explained above.


> 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.

I won't argue about this one.  The actual syntax of the NA is not an
issue for me, as long as there is a simple mapping from every NA into
a domain name that can be potentially registered in the DNS-based
registry.  Right-to-left NA names with dot separators are fine;
left-to-right NA names with slash separators are also fine: as long as
we pick exactly one of those.


> 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?

I'd state this a bit differently: anyone who has a chunk of domain
space delegated to her can define a naming authority name under that
chunk of domain space.  (I wouldn't expect there to be nearly as many
naming authorities as, say, domain names of hosts.)


There is a subtle but important difference between:

a. The URN system must guarantee persistence, and
b. Clients should be able to assume persistent URNs.

I think we can reasonably acheive the second, but not the first.

As several people have observed, persistence is largely a matter of
discipline in name assignment, and committment to provide resolution
services (using whatever protocols are currently in vogue) over the
useful life of the resource.

While domain names for hosts are frequently reassigned, it is possible
to define domain names in ordinary DNS space that are unlikely to be
reassigned.  For example, the University of Tennessee could define a
NA of urn.utk.edu for the purpose of assigning URNs.  Reassignment of
utk.edu is unlikely, and the University of Tennessee, if it chose,
could make a commitment to maintain the urn.utk.edu name and its
resolution services for many decades.

In rare cases, domain names have been forcibly reassigned to other
parties.  This is one reason for the proposal for a .URN top-level
domain, under which reassignment would be prohibited.  But there would
probably be other constraints on both names under .URN and operation
of the DNS-based registry under .URN to better ensure long-term
persistence.  Due to the additional costs imposed by these
constraints, membership in the .URN space might be unavailable to
small information providers.

Furthermore, even though there is a clear need for names which are
persistent over the long-term, there's also a need for URN-related
services for resources and resource names that only have short-term
utility.  While we'd like to discourage reassignment of such names in
any case, ordinary domain names will suffice as NAs for URNs for the
purpose of resolving many kinds of resources.  (It is still desirable
to prevent name collisions, but there are other ways of doing this:
e.g. we could require that a date be included in the LUI portion of a
URN)

Having naming authorities under both .URN and in ordinary domain space
is a compromise to provide for both maintenance of names in the
long-term (for those who can afford the best), and allowing anyone who
wants to be an information provider to assign URNs and provide
URN-based resolution services.


> 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?  

By defining new names under .URN for those legacy schemes, and
optionally establishing pointers to resolution services for those
names in the DNS-based registry.


> 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.

The UTK group's proposal for URNs was not intended as a single
"scheme" among peers.  It *was* intended as an umbrella which could
incorporate other naming schemes.  The proposal makes more sense when
viewed in this light.

Even if we had schemes in the URN, I'd still argue that we need a DNS
based registry which could incorporate *all* URNs - regardless of
scheme - and which allowed those who assign URNs to advertise
resolution services for those URNs, and which allowed those services
to change over time.


> 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?  

(whew)

okay, in order:

a. The NA is not coupled with the resolution service.  Not at all.
The binding between the URN and its resolution services is provided by
one or more registries, and thus can be changed at any time.

b. Under this scheme, yes it is possible for a URN to have several
different resolution servers -- simply by listing multiple services in
the registry.  We are looking at various ways to specify resolution
services for subspaces of the URN space under an NA.  

(As for *translation* of different parts of the namespace, the ideas
we discussed at the UTK meeting would at least allow it for particular
resolution protocols.)

c. The worst case scenario (of maximum entropy of the URN->resolution
service mapping within an NA's portion of URN space) is handled by
delegating the resolution service (in each registry) to a service
which handles large flat name spaces and issues "redirects" to other
servers as needed.  This "flat" resolution service need not be
provided by the NA itself, since the NA can issue redirects to other
servers.

d. You and I agree that the resolution service should not be coupled
with the object.  On the other hand, it's assumed to be likely
(especially for recently defined objects) that there is a strong
correlation between the NA that assigned a resource name and the
entity that provides resolution services for that names.  This system
proposed at the UTK meeting optimizes for lookup of recently defined
names (by aggregating the mapping of names defined under an NA to
resolution services), but still allows arbitrary mapping of names to
service locations (by allowing those resolution services to issue
redirects).


> 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.

The UTK report says nothing about particular resolution protocols,
only about the syntax of URNs in general and the DNS-based registry
for mapping URNs to services, protocols, and service locations.

What I mean is: I think we've tried to define the "outside" mechanism
rather than the "inside" one.  Perhaps it seems otherwise because so
many of the UTK meeting participants had proposed DNS-based URN
schemes, but what we were looking for at UTK was a way to bring an
acceptable level of commonality to all URN schemes.

Keith

Received on Tuesday, 21 November 1995 22:08:41 UTC