view Side-By-Side changes

INTERNET DRAFT



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
draft-ietf-urn-nid-req-01.txt
                                             DSTC Pty Ltd
25 March, 1997
                                             Patrik Faltstrom
                                             Tele2/Swipnet

            Namespace Identifier Requirements for



      URN Services Namespace Registration and Standardization Process Mechanisms


Status of this Memo
=================== 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 
     "work in progress.' progress."

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

    This draft expires 25 September, 1997.


Abstract:
=========

Services that offer to resolve Uniform Resource Names implicitly
require that they support



Abstract

The URN WG has defined a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements syntax for
any such service that wishes to participate as a Namespace Identifier.


Introduction:
=============

The Uniform Resource Name (URN) Working Group has defined Names
(URNs) [RFC2141], as well as some proposed mechanisms for both the syntax [4] and their
resolution of URNs [1,2]. An framework
for URN discovery systems has also been outlined [3]. This draft
discusses and recommends use in Internet applications ([RFC2168, RFC2169]).    
The whole rests on the requirements for entities that wish
to act as Namespace Identifiers (NIDs) concept of individual ''namespaces'' within the
URN system.

The URN syntax includes the NID which acts as structure.  Apart from  proof-of-concept namespaces, the scoping
indicator use
of existing identifiers in URNs has been discussed (??? biblio id 
document). This document lays out general definitions of and mechanisms 
for the URN. The NID indicates which Namespace
the establishing URN belongs to and gives hints ''namespaces''. 


Foreword to the underlying resolution
service.

Consider the following example URNs:

   urn:znet:metadata.net:dc
   urn:buns:555555:annual-report
   urn:hoptus:priv:555-ABCD this Edition

This document is a very drafty draft.  The NIDs in these cases, "znet", "buns", and "hoptus" all
act as top-level namespaces, and hence, must meet certain
guidelines intention of this version
is to ensure meeting all the URN requirements [5].
In particular:
   - Global Scope and Uniqueness
   - Persistence
   - Independence
   - Resolution


Requirements:
=============

Given the four categories above, lay out the requirements groundwork for each our
now outlined.


 Global Scope and Uniqueness.

  - The NID must some proposed processes.  Detail will
be registered with needed.  No one has formally approached IANA to ensure uniqueness and
    demonstrating that it meets set up the requirements listed in registry
this
    document.
  - 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 simple and limited character set should be imposed URN namespace itself has an identifier in order to 
    support

	. ensure global access (as described in [4]).
  - Rules on how uniqueness of URNs
	. (where desired) provide a cue for the Namespace Specific String structure of the identifier

For example, ISBNs and ISSNs are allocated
    must be documented.
  - Definitions both collections of terms like "equal" identifiers used
in the traditional publishing world; while there may some number (or numbers) 
that is both a valid ISBN identifier and "different" ISSN identifier, using different 
designators for resources
    must be published.

 Persistence

  - The NID service providers must show the two collections ensures that they intend to
    support no two URNs will be the service same 
for different resources.

The development of an indefinite period identifier structure, and thereby a collection
of time.
  - Support facilities must identifiers, is a process that is inherently dependent on the needs
of the identifiers, how they will be described assigned, and how the service
    intends uses to operate, including "disaster recovery"-like
    operations.
  - Demonstrated experience in managing an established namespace
    system is essential.    
  - One URN should never which they 
will be reused 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 different resource (where
    "different" is defined as in previous paragraph by given namespace
	. determination of failure of support for a namespace

Different levels of disclosure are expected/defined for namespaces.
According to the namespace).
    The level of discussion and standardization surrounding the
disclosure, a URN should namespace may be persistent for all times, even though the
    resource goes away.

 Independence

  - The NID service providers must also show any relationship
    (both technical and administrative) that assigned or may impede on request a particular
identifier.

Note that this document restricts itself to the
    provision description of processes
for the creation of URN service.
  - However, multi-party participation in the NID service namespaces.  If "resolution" of any so-created
URN identifiers is
    an advantage.

 Resolution

  - The desired, a separate process of registration in a global
NID service providers must produce an RFC
    describing directory, such as that provided by the technical characteristics NAPTR [Ref ??] system,  is
necessary.


URN Namespace Categories

There are 4 categories of the URN
    resolution service, including security considerations.
  - 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 service providers may elect be any valid NID string
		that does not to have the
    resolution service publically available.


Example:
=======

(1) urn:buns:555555:annual-report

This URN, in the namespace called "buns" clash with an existing, registered NID.

The fourth is referring to the
document named annual-report, in postscript format. 

At a composite namespace type (i.e., one constructed for
the express purpose of later stage, that resource subdivision):

	 IV. Top-level: These are processed through a full standards-track
		RFC review process.  The result is replaced by not a NID so much 
		as a text version, top-level NID structure, which
lacks will be subdivided by the pictures, but that is ok, because 
		rules laid out in the namespace has decided
that postscript format documents and text documents top-level NID RFC.  These NID
		strings must not clash with existing, registered NIDs;
		additionally, the RFC1766 country code strings are considered 
		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
same even though following
information must be provided to the figures doesn't exist in IANA:

Declared owner of the textual version.

In namespace
Description of:

	. uniqueness of identifiers assigned by the third stage, namespace's naming
	  authority
	. process of assignment of identfiers in the report is removed, and replaced with a report namespace
	. rules for determining lexical equivalence between identifiers in the 
	  namespace
	. identification of validation mechanism (to ascertain whether or
	  not a different year. This new report gets string is in fact a new valid URN because it is
considered being in the namespace).  This
	  can include:
		. a different document. syntax grammar
		. an on-line service
		. an off-line service
	. conformance with RFC1737 requirements (??? these should be
	  listed out)

The old URN namespace is never reused.

(2) urn:foo:bar:current-weather
    urn:foo:bar:weather/19970325

These are two URNs referring at one stage then identified by the declared owner's private OID (POID)
and a suffix to distinguish among different namespaces assigned to the
same resource, i.e.
on POID:  POID.##


Standardization Process 


To establish a standardized URN namespace, the 25th following information
must be described and vetted in an IETF standards-track RFC:

Declared owner of March 1997. On the 26th namespace
Desired NID
Description of:

	. uniqueness of March 1997,
urn:foo:bar:current-weather is referring to identifiers assigned by the same resource as
urn:foo:bar:weather/19970326.

Conclusion:
===========

This draft has outlined namespace's naming
	  authority
	. process of assignment of identfiers in the requirements namespace
	. rules for providers determining lexical equivalence between identifiers in the 
	  namespace
	. conformance with RFC1737 requirements (??? these should be
	  listed out)
	. identification of
NID services for URN systems. The objective validation mechanism (to ascertain whether or
	  not a string is to maintain in fact a high persistence rate for valid URN services, and these requirements
are aimed at ensuring a high level in the namespace) (??? in
	  this case, it is required to be one of service stability.



References:
===========

[1] 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", draft-ietf-urn-naptr-02.txt,
    February, RFC 2168 June 1997.

[2]

[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
    draft-ietf-urn-http-conv-01.txt, February 1997

[3] Karen R Sollins, "Requirements and a Framework for URN Resolution
    Systems", draft-ietf-urn-req-frame-00.txt, November 1996

[4]
    RFC 2169, June 1997.

[RFC2141] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January RFC 2141, May 1997.

[5]

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


Security Considerations
=======================

It is a requirement that it in the definitions of a namespace are
included sections on security covering for example:

  + Spoofing of servers
  + Verification of responses

Because a namespace can decide that a resolution service is not
publically available, it is possible to use firewall installations and
other traffic limiting constructions to diconnect the namespace from
the global Internet.

Author Contact Information:
===========================




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




----