Subject: RE: [URN] WG last call: URN Namespace Definition Mechanisms

From: Yves Arrouye <[email-masked]>
Date: Mon, 12 Oct 1998 16:12:43 -0700

> >It would seem that these can't be easily handled by  having a
> >country-code URN namespace then having the country parcel it out
> >for country-unique spaces. I could imagine reserving the names
> >"xx-<blah>" for country xx, so that "us-ssn" would be recommended
> >over "ssn" to distinguish it from "dk-ssn", but I'd think that
> >each of these should be registered separately.

I think that would be nice indeed. Different registrations would help
delegate the authority for these different namespaces to the appropriate
people, and if we keep the current resolution discovery (where one looks at
NID.urn.net) different namespaces could easily specify different resolution
mechanisms. "us-ssn" and "us-something else" could have totally different
NAPTRs entries with no extra complexity.

Yves.

---

From: [email-masked] (Claus André Färber)
Date: 13 Oct 1998 17:27:00 +0200

> NAPTRs entries with no extra complexity.

The main issue here is whether to use flat namespaces, where the  
namespace identifiers have a structure, that is not reflected in the way  
URNs are resolved or to use hierarchical namespaces, where a namespace  
may be defined in a way that allows the URN to have a syntax like  
<URN:nid:subnid:subsubnid:identifier>.

Why not allow both and leave it to those who register namespaces? This  
would only mean we have to reserve <country-code> as well as <country- 
code> "-" <anything>.

Yes, I believe the URN syntax and the NAPTR resoultion are flexible  
enough to allow the later (see examples below).

BTW, the possibility of partitioning namespace is explicitly mentioned:

|	  Possible answers include, but are not limited to:

|	.   exposition of the structure of the identifiers, and
|	    partitioning of the space of identifiers amongst
|	    assignment authorities which are individually responsible
|	    for respecting uniqueness rules

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Example for NAPTR records with subnamspaces: (I didn't use a country  
code as an examle but another NID you might already know.)

ietf.urn.net
  IN NAPTR 100 10 "" "" "/urn:ietf:([^:]+):.*/\1\.urn\.ietf\.org/i" .

rfc.urn.ietf.org
  IN NAPTR 100 10 "s" "http+U2R+U2C+" ;; ...
  ;; ...

id.irn.ietf.org
  IN NAPTR 100 10 "s" "http...
  ;; ...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Example for Registration of Namespaces that allow Subnamespaces #1: IETF

Namespace ID: ietf

Registration Information:
  Version: 1
  Date: 1998-XX-YY

Declared registrant of the namespace:  IETF
  E-Mail: [email-masked]

Declaration of syntactic structure:
  IETF namespaces have the form urn:ietf:<series>:<identifier>,
  where <series> is one of "rfc", "bcp", "id", "std" ...
  and <identifier> is a identifier the format of which is defined
  by the definition of the <series> subnamespaces in [XXX].

Relevant ancillary documentation:
  [XXX]

Identifier uniqueness considerations:
  The set of identifiers for the <series> part chages very rarely and
  no two document series will be assigned the same name by IETF.

  The uniqueness of identifiers is handled by the manager of each
  subnamespace, i.e. the Internet Draft Editor for the id series or
  the RFC Editor for the rfc series.

Identifier persistence considerations:
Process of identifier assignment:
  [ see draft for IETF namespace ]

Process for identifier resolution:
  Namespace will be registered within urn.net [RFCXXXX].

Rules for Lexical Equivalence:
  [ see draft for IETF namespace ]

Conformance with URN Syntax:
  no special considerations

Validation mechanism:
  [see draft for IETF namspace ]

Scope:
  Global.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Example for Registration of Namespaces that allow Subnamespaces #2: XX  
National Namespace

Namespace ID: xx

Registration Information:
  Version: 1
  Date: 1998-XX-YY
{{ Note:
  The definition of THIS namespace does not change by adding new
  subnamespaces, just as the definition of a non-hierarchical namespace
  does not change by assigning identifiers.}}

Declared registrant of the namespace:  IETF
  E-Mail: [email-masked]

Declaration of syntactic structure:
  This namespace has the form <urn:xx:<snid>:<ident>>, where <snid> is
  a subnamespace registered with XX National URN Registration and
  <ident> is a identifier the structure of which is defined with the
  registrations of each <snid>.

{{ Legal, as the following is allowed in the draft:
|	  . the structure is opaque (no exposition) }}

Relevant ancillary documentation:
  The procedures for defining subnnamespaces are definied in [XXX].

Identifier uniqueness considerations:
  Subnamespace uniqueness is guaranteed by XX National URN Registration.
  The registrators of subnamespaces are responsible for the uniqueness
  of identifiers within their subnamespace.

{{ Legal due to:
|	  . exposition of the structure of the identifiers, and
|	    partitioning of the space of identifiers amongst
|	    assignment authorities which are individually responsible
|	    for respecting uniqueness rules
|	  . information is withheld; the namespace is opaque }}

Identifier persistence considerations:
  Persistance issues are handled by the registrators of subnamespaces.

{{ Legal due to:
|	  . quality of service considerations }}

Process of identifier assignment:
  Subnamespaces are assigned with XX National URN Registration. The
  process of assignement of identifiers within each subnamaspace is
  definied in their registrations.

{{ Legal due to:
|	  . assignment is delegated to authorities recognized by
|	    a particular organization (e.g., the Digital Object
|	    Identifier Foundation controls the DOI assignment space and
|	    its delegation)
|	  . assignment is completely closed (e.g., for a private
|	    organization) }}

Process for identifier resolution:
  The XX namespace is registers within urn.net, where the resolution of   
  subnamespaces will be delegated to their registrators.

{{ Legal due to:
|	  . resolution is controlled by entities to which assignment
|	    has been delegated }}

Rules for Lexical Equivalence:
  The <snid> part is case insensitive. The lexical equivalence of the
  <ident> part is definied in the registrations of each subnamespace.

{{ Legal, as equivalence rules need not be defined at all and there is  
nothing that would prevent complex rules such as: xxx-0123 is equivalent  
to xxx-123, while yyy-0123 and yyy-123 are _not_ equal. }}

Conformance with URN Syntax:
  The strcuture of the namespace conforms to the URN syntax.
  Subnamespaces which need special handling to conform to that syntax
  can be registered, if the issue is handled in the registration.

{{ I believe that is legal, as it ensures that the issue is handled  
completly by delegation }}

Validation mechanism:
  The <snid> part has a syntax equivalent to that of top level URN
  namespaces. Each subnamespace may define further validation
  mechanisms.

{{ Should be legal, as providing validation is not mandatory. }}

Scope:
  Nation XX.