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

Keith,

In your message to Roy Fielding, you said:

>I could personally live with having a "name space identifier" (NSI)
>in the URN as long as (a) it's not strictly tied to a protocol or
>registry, (b) the resolution of the URN doesn't depend on the client
>knowing details of the NSI portion of the URN, (c) a registry can
>delegate resolution of URNs on at least a per-(NSI+NA) basis (and
>ideally, to smaller sub-ranges of that space).

This could be the basis for agreement amongst all parties.  Can you tell me
if I understand the implications?

(a)  "It's not strictly tied to a protocol or registry."  Presumably this
is to permit different resolution-systems to be used for a given NSI.  It
seems essential, so that (a) URNs can persist beyond the life of specific
protocols or resolution-systems, (b) organizations can develop and run
their own resolution-systems.

(b)  "The resolution of the URN doesn't depend on the client knowing
details of the NSI portion of the URN."  Is this satisfied by the client's
default being to pass the URN to a registry?  The registry would know about
the NSI, but NSI-specific code does not have to be built into every client.


(c)  "A registry can delegate resolution of URNs on at least a per-(NSI+NA)
basis (and
ideally, to smaller sub-ranges of that space."  I have mixed feeling about
including the NA, because of the potential to generate a huge data
structure that must be maintained by every registry.  (See below for an
analysis.)  However, my understanding of your NAPTR proposal is that it
permits aggregation.  For example, the registry could contain a single
record that all URNs for all NAs within a given NSI are resolved in the
same way.  Is this correct?

Bill

=======================================================

THE DATA STRUCTURE MAINTAINED BY A URN REGISTRY

A URN registry is provides a mapping between URNs and resolution-systems.

URN space is a tree:
  The top node is "URN".
  Second level nodes are NSIs, name space identifiers.
  Below are NAs, naming authorities, which themselves are hierarchical.
  Below are individual URNs.

Our hope is that registries will be very simple systems or simple add-ons
to existing systems.  The complexity depends on:
a)  The number of nodes that each registry has to keep explicit records for.
b)  Whether NSIs have to report to the registries when they create new NAs.
c)  Whether NAs have to report to the registries when they create new URNs.

Very rough guesses at the population of this tree five years from now are:
  Top node: 1
  NSIs: 10
  NAs: 100,000+
  URNs: 100,000,000

These numbers show that it is a simple task to maintain a registry of NSIs,
but potentially a big task to maintain a registry of NSIs+NAs.  If,
however, people wish to permit a NSI+NA granularity, a possible balance is:
a)  To require each registry to have an explicit record for each NSI.
b)  To permit each registry to include explicit records for NAs.
c)  To make reporting of new name authorities by NSIs optional.
d)  When the registry has no explicit record for an NA, the record for its
parent is implied.

Received on Wednesday, 29 November 1995 09:57:34 UTC