[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 05 06 07 08 rfc2611                               
INTERNET DRAFT                                             Renato Iannella
draft-ietf-urn-nid-req-01.txt                                 DSTC Pty Ltd
25 March, 1997                                            Patrik Faltstrom

            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.


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.


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

Consider the following example URNs:


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


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
  - 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.


  - 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
  - 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.


  - 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.


  - 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.


(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

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


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.


[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
voice:  +61 7 3365 4310
fax:    +61 7 3365 4311
email:  renato@dstc.edu.au

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