URN Namespace Definition Mechanisms
RFC 2611

Document Type RFC - Best Current Practice (June 1999; No errata)
Obsoleted by RFC 3406
Also known as BCP 33
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2611 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          L. Daigle
Request for Comments: 2611                      Thinking Cat Enterprises
BCP: 33                                                     D. van Gulik
Category: Best Current Practice                      ISIS/CEO, JRC Ispra
                                                             R. Iannella
                                                            DSTC Pty Ltd
                                                            P. Faltstrom
                                                           Tele2/Swipnet
                                                               June 1999

                  URN Namespace Definition Mechanisms

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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 ([RFC2288]), and this
   document lays out general definitions of and mechanisms for
   establishing URN "namespaces".

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 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 the rules of a
      particular namespace (in terms of syntax, semantics, and process).

Daigle, et al.           Best Current Practice                  [Page 1]
RFC 2611          URN Namespace Definition Mechanisms          June 1999

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

   The purpose of this document is to 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 Internet Assigned Numbers Authority, 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 desired, a separate process of
   registration in a global NID directory, such as that provided by the
   NAPTR system [RFC2168], is necessary.  See [NAPTR-REG] for
   information on obtaining registration in the NAPTR global NID
   directory.

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 be 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
   requirements of the community defining the identifier, 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.

Daigle, et al.           Best Current Practice                  [Page 2]
RFC 2611          URN Namespace Definition Mechanisms          June 1999

   This document outlines the processes by which a collection of
   identifiers satisfying certain constraints (uniqueness of assignment,
   etc) can become a bona fide URN namespace by obtaining a NID.  In a
   nutshell, a template for the definition of the namespace is completed
   for deposit with IANA, and a NID is assigned.  The details of the
   process and possibilities for NID strings are outlined below; first,
   a template for the definition is provided.
Show full document text