RFC 2611 (rfc2611) - Page 2 of 14
URN Namespace Definition Mechanisms
Alternative Format: Original Text Document
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 [RFC 2168], 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