view Side-By-Side changes

Internet Draft                               Leslie L. Daigle
November 19, 1997
March 11, 1998                               Bunyip Information Systems
draft-ietf-urn-nid-req-02.txt
draft-ietf-urn-nid-req-03.txt                Dirk-Willem van Gulik
                                             ISIS/CEO, JRC Ispra
                                             Renato Iannella
                                             DSTC Pty Ltd
                                             Patrik Faltstrom
                                             Tele2/Swipnet



      URN Namespace Registration and Standardization Process Definition Mechanisms


Status of this Document

     This document is an Internet-Draft.  Internet-Drafts are working  
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also  
     distribute working documents as Internet-Drafts. 

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as 
     "work in progress."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
     Coast), or ftp.isi.edu (US West Coast).



0.0 Abstract

The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]).    
The whole rests on the concept of individual ''namespaces'' within the
URN structure.  Apart from  proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed (??? biblio id 
document). This ([RFC2288]),
and this document lays out general definitions of and 
mechanisms for establishing URN ''namespaces''. 


0.1 Foreword to this Edition

This document

For the purposes of this document, an "IANA-like" entity is assumed to
exist.  Anywhere the term "IANA" appears, consider it a very drafty draft.  The intention pointer to
whatever organization or entity exists to handle Internet
registration/assignment tasks.

Still notably absent:

	. where to _send_ and/or _discuss_ the declarations
	  defined here
	. process mechanisms for assigning/obtaining specific NIDs.

These details must wait until there is general resolution re.
Internet assigned numbers.


1.0 Introduction

Uniform Resource Names (URNs) are resource identifiers with the
specific requirements for enabling location independent
identification of a resource, as well as longevity of reference.
There are 2 assumptions that are key to this version document:

Assumption #1:

   Assignment of a URN is a managed process.

   I.e., not all strings that conform to URN syntax are necessarily
   valid URNs.  A URN is assigned according to lay out the groundwork for some proposed processes.  Detail will rules of a 
   particular namespace (in terms of syntax, semantics, and process).


Assumption #2:

   The space of URN namespaces is managed.
   
   I.e., not all syntactically correct URN namespaces (per the URN
   syntax definition)  are valid URN namespaces.  A URN namespace
   must have a recognized definition in order to be needed.  No one has formally approached IANA valid.


The purpose of this document is to set up outline a mechanism and provide a
template for explicit namespace definition, along with the mechanism
for associating an identifier (called a "Namespace ID", or NID) which
is registered with the registry IANA.

Note that this document restricts itself to the description of
processes for the creation of URN namespaces.  If "resolution" of any
so-created URN identifiers is defining.  The model here desired, a separate process of
registration in a global NID directory, such as that provided by the
NAPTR system [RFC2168], is not unlike media type registrations.


Introduction necessary.


2.0 What is a URN Namespace?

For the purposes of URNs, a "namespace" is a collection of
uniquely-assigned identifiers.  A URN namespace itself has an
identifier in order to

	. ensure global uniqueness of URNs
	. (where desired) provide a cue for the structure of the
	  identifier

For example, ISBNs and ISSNs are both collections of identifiers used
in the traditional publishing world; while there may some number (or
numbers) that is both a valid ISBN identifier and ISSN identifier,
using different designators for the two collections ensures that no
two URNs will be the same for different resources.

The development of an identifier structure, and thereby a collection
of identifiers, is a process that is inherently dependent on the needs
of the identifiers, how they will be assigned, and the uses to which
they will be put.  All of these issues are specific to the individual
community seeking to define a namespace (e.g., publishing community,
association of booksellers, protocol developers, etc); they are beyond
the scope of the IETF URN work.

This document concerns itself with outlines the mechanical processes of associating
an identifier string with by which a predefined namespace and publication collection of
identifier structures.  Of particular concern are:

	. selection
identifiers satisfying certain constraints (uniqueness of strings to associate with assignment,
etc) can become a bona fide URN namespace
	. publication of structural elements of by obtaining a NID.  In a
nutshell, a template for the identifiers
	. identification definition of support infrastructure the namespace is completed
for assignment deposit with IANA, and resolution of URNs for a given namespace
	. determination of failure NID is assigned.  The details of the
process and possibilities for NID strings are outlined below; first, a
template for the definition is provided.


3.0 URN Namespace Definition Template

Definition of a URN namespace is accomplished by completing the
following information template.  Apart from providing a mechanism
for disclosing structure of the URN namespace, this information
is designed to be useful for

	. entities seeking to have a URN assigned in a namespace
	  (if applicable)
        . entities seeking to provide URN resolvers for a namespace 
	  (if applicable)

This is particularly important for communities evaluating the
possibility of using a portion of an existing URN namespace rather 
than creating their own.

Information in the template is as follows:

Namespace ID:
	
	Assigned by IANA.  In some contexts, a particular one
	may be requested (see below).

Declared registrant of the namespace:  

	Name and e-mail address.

Declaration of structure:

	This section should outline any structural features of
	identifiers in this namespace.  At the very least, this
	description may be used to introduce terminology used in
	other sections.  This structure may also be used for
	determining realistic caching/shortcuts approaches; suitable 
	caveats should be provided.

	Answers might include, but are not limited to:

	. the structure is opaque (no exposition)
	. a regular expression for parsing the identifier into
	  components, including naming authorities



Identifier uniqueness considerations:
	
	This section should address the requirement that 
	URN identifiers be assigned uniquely -- they are assigned
	to at most one resource, and are not reassigned.

	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
	. identifiers are assigned sequentially
	. information is withheld; the namespace is opaque


Identifier persistence considerations:

	Although non-reassignment of URN identifiers ensures
	that a URN will persist in identifying a particular
	resource even after the "lifetime of the resource", 
	some consideration should be given to the persistence
	of the usability of the URN.  This is particularly
	important in the case of URN namespaces providing 
	global resolution.

	Possible answers include, but are not limited to:

	. quality of service considerations


Process of identifier assignment:

	This section should detail the mechanisms and or authorities
	for assigning URNs to resources.  It should make clear whether
	assignment is completely open, or if limited, how
	to become an assigner of identifiers, and/or get one
	assigned by existing assignment authorities.  Answers
	could include, but are not limited to:

	. assignment is completely open, following a particular
	  algorithm
	. 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:

	If a namespace is intended to be accessible for global
	resolution, it must be registerd in an RDS (Resolution
	Discovery System, see [RFC2276]) such as NAPTR.  Resolution
	then proceeds according to standard URI resolution processes,
	and the mechanisms of the RDS.  What this section should
	outline is the requirements for becoming a recognized resolver 
	of URNs in this namespace (and being so-listed in the RDS
	registry).

	Answers may include, but are not limited to:

	. the namespace is not listed with an RDS; this is not
	  relevant
	. resolution mirroring is completely open, with a mechanism
	  for updating an appropriate RDS
	. resolution is controlled by entities to which assignment
	  has been delegated


Rules for Lexical Equivalence:

	If there are particular algorithms for determining
	equivalence between two URN strings in this namespace,
	rules can be provided here.  

	Some examples include:
	
	. mappings between different character set encodings
	. equivalence between hyphenated and non-hyphenated
	  groupings in the identifier string


Conformance with URN Syntax:

	This section should outline any special considerations
	required for conforming with the URN syntax.  This is
	particularly applicable in the case of legacy naming
	systems that are used in the context of URNs.

	For example, if a namespace is used in contexts other 
	than URNs, it may have a more generous character set than is 
	immediately available with URNs.  This section should flag this
	issue and outline necessary mappings to conform to 
	URN syntax.  (E.g., see the section on SICIs in [RFC2288]).

Validation mechanism:

	Apart from attempting resolution of support a URN, a URN namespace
	may provide mechanism for "validating" a URN -- i.e., 
	determining whether a given string is currently a
	validly-assigned URN.  For example, even if an ISBN
	URN namespace is created, it is not clear that
	all ISBNs will translate directly into "assigned URNs".

	A validation mechanims might be:

	. a syntax grammar
	. an on-line service
	. an off-line service


Scope:
	
	This section should outline the scope of the use of the
	identifiers in this namespace.  Apart from considerations
	of private vs. public namespaces, this section is critical
	in evaluating the applicability of a requested NID.  For
	example, a namespace claiming to deal in "social security
	numbers" should have a global scope and address all 
	social security number structures (unlikely).  On the
	other hand, at a national level, it is reasonable to
	posit a URN namespace for "this nation's social security
	numbers".



4.0 URN Namespace Registration and NID Assignment

Different levels of disclosure are expected/defined for namespaces.
According to the level of open-forum  discussion and standardization surrounding
the disclosure, a URN namespace may be assigned or may request a
particular identifier.

Note that this document restricts itself to the description of processes
for the creation of URN namespaces.  If "resolution" of any so-created
URN identifiers is desired, a separate process of registration in a global
NID directory, such as that provided by the NAPTR [Ref ??] system,  is
necessary.


URN Namespace Categories

There are 4 3 categories of URN namespaces defined here, distinguished
by expected level of service and required procedures for registration.

The first three are simple namespace types:

	  I.


	  I.. Experimental: These are not registered with IANA. They
	        take the form

		x-<NID>

	 II. Informal:  These are registered with IANA (see Section ??), and
		are assigned a number based on a private OID ("POID" 
		namespaces). sequence as an identifier.

	III. Standardized: Formal:  These are processed through a full standards-track RFC review 
	 	process.  The NID may be any valid NID string
		that does not start with "x-" (see Type I above), and
		doesn't clash with an existing, registered NID.

		The fourth is a composite namespace type (i.e., one constructed for
the express purpose of later subdivision):

	 IV. Top-level: These are processed through a full standards-track
		RFC review process.  The result is not a NID so much 
		as a top-level NID structure, which will be subdivided by the 
		rules laid out in the top-level NID RFC.  These NID
		strings must not clash with existing, registered NIDs;
		additionally, the RFC1766 two-letter country code strings codes are reserved
		for use by countries that desire to so-obtain
		a top-level NID.



Registration Procedures

To register a availability for national registrations.



5.0 Example

A generic "Internet" namespace has been posited throughout recent
discussions of URNs. This namespace (for type II namespaces, informal), the following
information must might be provided to the IANA: defined as follows:

Namespace ID:
	
	"INET" requested.
	
Declared owner of the namespace
Description of:

	. uniqueness of identifiers assigned by the namespace's naming
	  authority
	. process of assignment registrant of identfiers in the namespace
	. rules for determining lexical equivalence between identifiers in the 
	  namespace
	. identification namespace:  

	T. Cat
	leslie@thinkingcat.com


Declaration of validation mechanism (to ascertain whether or
	  not structure:

	The identifier structure is as follows:
	
	FQDN:<assigned string>

	where FQDN is a fully-qualified domain name, and the
	assigned string is in fact a valid conformant to URN in the namespace).  This
	  can include:
		. a syntax grammar
		. an on-line service
		. an off-line service
	. conformance with RFC1737 requirements (??? these should be
	  listed out)

The namespace requirements.


Identifier uniqueness considerations:
	
	Uniqueness is then identified by guaranteed as long as the declared owner's private OID (POID)
and a suffix to distinguish among different namespaces assigned to the
same POID:  POID.##


Standardization Process 


To establish
	string is never reassigned for a standardized URN namespace, the following information
must be described and vetted in an IETF standards-track RFC:

Declared owner of the namespace
Desired NID
Description of:

	. uniqueness given FQDN.	
	

Identifier persistence considerations:

	Persistence of identifiers assigned by is dependent upon suitable
	delegation of resolution at the namespace's naming
	  authority
	. process level of assignment "FQDN"s.

Process of identifier assignment:

	Assignment of these URNs delegated to individual domain
	name holders (for FQDNs).  The holder of identfiers in the namespace
	. rules for determining lexical equivalence between identifiers FQDN registration
	is required to maintain an entry (or delegate it) in the 
	  namespace
	. conformance with RFC1737 requirements (???
	NAPTR RDS.  Within each of these should delegated name partitions,
	the string may be
	  listed out)
	. identification of validation mechanism (to ascertain whether assigned per local requirements.

	e.g.  urn:inet:thinkincat.com:001203



Process for identifier resolution:

	Domain name holders are responsible for operating or
	  not a string is
	delegating resolution servers for the FQDN in fact a valid URN which they
	have assigned URNs.


Rules for Lexical Equivalence:

	Nothing in particular.

Conformance with URN Syntax:

	No special considerations.

Validation mechanism:

	None specified.

Scope:
	
	Global.





6.0 Security Considerations

This document largely focuses on providing mechanisms for the namespace) (??? in
	  this case, it is required to be one
declaration of whois, finger, mail
	  service)
	. match public information.  Nominally, these declarations
should be of scope, ownership, and/or global applicability. (?? E.g.,
	  you can't ask for "social relatively low security numbers", but profile, however there is
always the US
	  may ask for US social security numbers).



Examples



Security Considerations

(??? THere will most assuredly danger of "spoofing" and providing mis-information.
Information in these declarations should be some!). taken as advisory.




7.0 References


[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 
    Resource Identifiers using the Domain Name System", RFC 2168 2168,
    June 1997.

[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 
    Resolution", RFC 2169, June 1997.

[RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 
    Bibliographic Identifiers as Uniform Resource Names", RFC 2288,
    February 1998.

[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997.

[RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 
    for Uniform Resource Names", RFC1737, December 1994

[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 
    Name Resolution", RFC 2276, January 1998.




8.0 Authors' Addresses

Leslie L. Daigle
Bunyip Information Systems Inc
310 Ste. Catherine St. W
Suite 300
Montreal, Quebec, CANADA
H2X 2A1
voice: +1 514 875-8611
fax:   +1 514 875-8134
email:  leslie@bunyip.com

Dirk-Willem van Gulik
ISIS/STA/CEO - TP 270
Joint Research Centre Ispra
21020 Ispra (Va)
Italy.
voice: +39 332 78 9549 or 5044  
fax:   +39 332 78 9185
email:  Dirk.vanGulik@jrc.it

Renato Iannella
DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
voice:  +61 7 3365 4310
fax:    +61 7 3365 4311
email:  renato@dstc.edu.au


Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN
voice:  +46-5626 4000
fax:    +46-5626 4200
email:  paf@swip.net




----