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



      URN Namespace Registration and Standardization Process 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).



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 document lays out general definitions of and mechanisms
for establishing URN ''namespaces''.


Foreword to this Edition

This document is a very drafty draft.  The intention of this version
is to lay out the groundwork for some proposed processes.  Detail will
be needed.  No one has formally approached IANA to set up the registry
this is defining.  The model here is not unlike media type registrations.


Introduction

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 beyond the scope of the URN
work.

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

        . selection of strings to associate with a namespace
        . publication of structural elements of the identifiers
        . identification of support infrastructure for assignment
          and resolution of URNs for a given namespace
        . determination of failure of support for a namespace

Different levels of disclosure are expected/defined for namespaces.
According to the level of 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 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. 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).

        III. Standardized:  These are processed through a full standards-track
                RFC review process.  The NID may be any valid NID string
                that does not 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 country code strings are
                reserved for use by countries that desire to so-obtain
                a top-level NID.



Registration Procedures

To register a namespace (for type II namespaces, informal), the following
information must be provided to the IANA:

Declared owner of the namespace
Description of:

        . uniqueness of identifiers assigned by the namespace's naming
          authority
        . process of assignment of identfiers in the namespace
        . rules for determining lexical equivalence between identifiers in the
          namespace
        . identification of validation mechanism (to ascertain whether or
          not a string is in fact a valid 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 is then identified by 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 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 of identifiers assigned by the namespace's naming
          authority
        . process of assignment of identfiers in the namespace
        . rules for determining lexical equivalence between identifiers in the
          namespace
        . conformance with RFC1737 requirements (??? these should be
          listed out)
        . identification of validation mechanism (to ascertain whether or
          not a string is in fact a valid URN in the namespace) (??? in
          this case, it is required to be one of whois, finger, mail
          service)
        . match of scope, ownership, and/or global applicability. (?? E.g.,
          you can't ask for "social security numbers", but the US
          may ask for US social security numbers).



Examples



Security Considerations

(??? THere will most assuredly be some!).



References


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

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

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

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




Authors' Addresses

Leslie L. Daigle
Bunyip Information Systems Inc
 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
 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