Message-Id: <firstname.lastname@example.org> Date: Wed, 29 Nov 1995 09:58:37 -0500 To: Keith Moore <email@example.com> From: "William Y. Arms" <warms@CNRI.Reston.VA.US> Subject: Re: URN Architecture Meeting at University of Tennessee, Oct 30-31 Cc: firstname.lastname@example.org 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.