INTERNET DRAFT                                             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



Status of this Memo
===================

    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 learn the current status of any Internet-Draft, please check
    the `1id-abstracts.txt' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.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 a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements for
any such service that wishes to participate as a Namespace Identifier.


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

The Uniform Resource Name (URN) Working Group has defined mechanisms
for both the syntax [4] and resolution of URNs [1,2]. An framework
for URN discovery systems has also been outlined [3]. This draft
discusses and recommends the requirements for entities that wish
to act as Namespace Identifiers (NIDs) within the URN system.

The URN syntax includes the NID which acts as the scoping
indicator for the URN. The NID indicates which Namespace
the URN belongs to and gives hints 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


The NIDs in these cases, "znet", "buns", and "hoptus" all
act as top-level namespaces, and hence, must meet certain
guidelines to ensure meeting all the URN requirements [5].
In particular:
   - Global Scope and Uniqueness
   - Persistence
   - Independence
   - Resolution


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

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


 Global Scope and Uniqueness.

  - The NID must be registered with IANA to ensure uniqueness and
    demonstrating that it meets the requirements listed in this
    document.
  - A simple and limited character set should be imposed to
    support global access (as described in [4]).
  - Rules on how the Namespace Specific String are allocated
    must be documented.
  - Definitions of terms like "equal" and "different" for resources
    must be published.

 Persistence

  - The NID service providers must show that they intend to
    support the service for an indefinite period of time.
  - Support facilities must be described and how the service
    intends to operate, including "disaster recovery"-like
    operations.
  - Demonstrated experience in managing an established namespace
    system is essential.
  - One URN should never be reused for a different resource (where
    "different" is defined as in previous paragraph by the namespace).
    The URN should 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 may impede on the
    provision of the URN service.
  - However, multi-party participation in the NID service is
    an advantage.

 Resolution

  - The NID service providers must produce an RFC
    describing the technical characteristics of the URN
    resolution service, including security considerations.
  - The NID service providers may elect not to have the
    resolution service publically available.


Example:
=======

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

This URN, in the namespace called "buns" is referring to the
document named annual-report, in postscript format.

At a later stage, that resource is replaced by a text version, which
lacks the pictures, but that is ok, because the namespace has decided
that postscript format documents and text documents are considered the
same even though the figures doesn't exist in the textual version.

In the third stage, the report is removed, and replaced with a report
for a different year. This new report gets a new URN because it is
considered being a different document.

The old URN is never reused.

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

These are two URNs referring at one stage to the same resource, i.e.
on the 25th of March 1997. On the 26th of March 1997,
urn:foo:bar:current-weather is referring to the same resource as
urn:foo:bar:weather/19970326.

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

This draft has outlined the requirements for providers of
NID services for URN systems. The objective is to maintain
a high persistence rate for URN services, and these requirements
are aimed at ensuring a high level of service stability.



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

[1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
    February, 1997.

[2] 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] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.

[5] 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:
===========================

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