draft-ietf-urn-nid-req-08.txt   rfc2611.txt 
Internet Draft Leslie L. Daigle Network Working Group L. Daigle
March 31, 1999 Bunyip Information Systems Request for Comments: 2611 Thinking Cat Enterprises
draft-ietf-urn-nid-req-08.txt Dirk-Willem van Gulik BCP: 33 D. van Gulik
ISIS/CEO, JRC Ispra Category: Best Current Practice ISIS/CEO, JRC Ispra
Renato Iannella R. Iannella
DSTC Pty Ltd DSTC Pty Ltd
Patrik Faltstrom P. Faltstrom
Tele2/Swipnet Tele2/Swipnet
June 1999
URN Namespace Definition Mechanisms
Status of This Document
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering URN Namespace Definition Mechanisms
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 Status of this Memo
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."
The list of current Internet-Drafts can be accessed at 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.
http://www.ietf.org/ietf/1id-abstracts.txt Copyright Notice
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (1999). All Rights Reserved.
http://www.ietf.org/shadow.html.
0.0 Abstract Abstract
The URN WG has defined a syntax for Uniform Resource Names The URN WG has defined a syntax for Uniform Resource Names (URNs)
(URNs) [RFC2141], as well as some proposed mechanisms for their [RFC2141], as well as some proposed mechanisms for their resolution
resolution and use in Internet applications ([RFC2168, RFC2169]). and use in Internet applications ([RFC2168, RFC2169]). The whole
The whole rests on the concept of individual "namespaces" within the rests on the concept of individual "namespaces" within the URN
URN structure. Apart from proof-of-concept namespaces, the use structure. Apart from proof-of-concept namespaces, the use of
of existing identifiers in URNs has been discussed ([RFC2288]), existing identifiers in URNs has been discussed ([RFC2288]), and this
and this document lays out general definitions of and document lays out general definitions of and mechanisms for
mechanisms for establishing URN "namespaces". establishing URN "namespaces".
1.0 Introduction 1.0 Introduction
Uniform Resource Names (URNs) are resource identifiers with the Uniform Resource Names (URNs) are resource identifiers with the
specific requirements for enabling location independent specific requirements for enabling location independent
identification of a resource, as well as longevity of reference. identification of a resource, as well as longevity of reference.
There are 2 assumptions that are key to this document: There are 2 assumptions that are key to this document:
Assumption #1: Assumption #1:
Assignment of a URN is a managed process. Assignment of a URN is a managed process.
I.e., not all strings that conform to URN syntax are necessarily I.e., not all strings that conform to URN syntax are necessarily
valid URNs. A URN is assigned according to the rules of a valid URNs. A URN is assigned according to the rules of a
particular namespace (in terms of syntax, semantics, and process). particular namespace (in terms of syntax, semantics, and process).
Assumption #2: Assumption #2:
The space of URN namespaces is managed. The space of URN namespaces is managed.
I.e., not all syntactically correct URN namespaces (per the URN I.e., not all syntactically correct URN namespaces (per the URN
syntax definition) are valid URN namespaces. A URN namespace syntax definition) are valid URN namespaces. A URN namespace
must have a recognized definition in order to be valid. must have a recognized definition in order to be valid.
The purpose of this document is to outline a mechanism and provide a The purpose of this document is to outline a mechanism and provide a
template for explicit namespace definition, along with the mechanism template for explicit namespace definition, along with the mechanism
for associating an identifier (called a "Namespace ID", or NID) which for associating an identifier (called a "Namespace ID", or NID) which
is registered with the Internet Assigned Number Authority, IANA. is registered with the Internet Assigned Numbers Authority, IANA.
Note that this document restricts itself to the description of Note that this document restricts itself to the description of
processes for the creation of URN namespaces. If "resolution" of any processes for the creation of URN namespaces. If "resolution" of any
so-created URN identifiers is desired, a separate process of so-created URN identifiers is desired, a separate process of
registration in a global NID directory, such as that provided by the registration in a global NID directory, such as that provided by the
NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for information NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for
on obtaining registration in the NAPTR global NID directory. information on obtaining registration in the NAPTR global NID
directory.
2.0 What is a URN Namespace? 2.0 What is a URN Namespace?
For the purposes of URNs, a "namespace" is a collection of For the purposes of URNs, a "namespace" is a collection of uniquely-
uniquely-assigned identifiers. A URN namespace itself has an assigned identifiers. A URN namespace itself has an identifier in
identifier in order to order to
. ensure global uniqueness of URNs - ensure global uniqueness of URNs
. (where desired) provide a cue for the structure of the - (where desired) provide a cue for the structure of the
identifier identifier
For example, ISBNs and ISSNs are both collections of identifiers used For example, ISBNs and ISSNs are both collections of identifiers used
in the traditional publishing world; while there may be some number (or in the traditional publishing world; while there may be some number
numbers) that is both a valid ISBN identifier and ISSN identifier, (or numbers) that is both a valid ISBN identifier and ISSN
using different designators for the two collections ensures that no identifier, using different designators for the two collections
two URNs will be the same for different resources. ensures that no two URNs will be the same for different resources.
The development of an identifier structure, and thereby a collection The development of an identifier structure, and thereby a collection
of identifiers, is a process that is inherently dependent on the of identifiers, is a process that is inherently dependent on the
requirements of the community defining the identifier, how they will requirements of the community defining the identifier, how they will
be assigned, and the uses to which they will be put. All of these 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 issues are specific to the individual community seeking to define a
namespace (e.g., publishing community, association of booksellers, namespace (e.g., publishing community, association of booksellers,
protocol developers, etc); they are beyond the scope of the IETF protocol developers, etc); they are beyond the scope of the IETF URN
URN work. work.
This document outlines the processes by which a collection of This document outlines the processes by which a collection of
identifiers satisfying certain constraints (uniqueness of assignment, identifiers satisfying certain constraints (uniqueness of assignment,
etc) can become a bona fide URN namespace by obtaining a NID. In a 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 nutshell, a template for the definition of the namespace is completed
for deposit with IANA, and a NID is assigned. The details of the for deposit with IANA, and a NID is assigned. The details of the
process and possibilities for NID strings are outlined below; first, a process and possibilities for NID strings are outlined below; first,
template for the definition is provided. a template for the definition is provided.
3.0 URN Namespace Definition Template 3.0 URN Namespace Definition Template
Definition of a URN namespace is accomplished by completing the Definition of a URN namespace is accomplished by completing the
following information template. Apart from providing a mechanism following information template. Apart from providing a mechanism for
for disclosing structure of the URN namespace, this information disclosing structure of the URN namespace, this information is
is designed to be useful for designed to be useful for
. entities seeking to have a URN assigned in a namespace - entities seeking to have a URN assigned in a namespace (if
(if applicable) applicable)
. entities seeking to provide URN resolvers for a namespace - entities seeking to provide URN resolvers for a namespace (if
(if applicable) applicable)
This is particularly important for communities evaluating the This is particularly important for communities evaluating the
possibility of using a portion of an existing URN namespace rather possibility of using a portion of an existing URN namespace rather
than creating their own. than creating their own.
Information in the template is as follows: Information in the template is as follows:
Namespace ID: Namespace ID:
Assigned by IANA. In some contexts, a particular one may be
requested (see below).
Assigned by IANA. In some contexts, a particular one Registration Information:
may be requested (see below).
Registration Information: This is information to identify the particular version of
registration information:
This is information to identify the particular version of - registration version number: starting with 1, incrementing by 1
registration information: with each new version
- registration date: date submitted to the IANA, using the format
YYYY-MM-DD
as outlined in [ISO8601].
. registration version number: starting with 1, incrementing by 1 Declared registrant of the namespace:
with each new version
. registration date: date submitted to the IANA, using
the format
YYYY-MM-DD
as outlined in [ISO8601].
Declared registrant of the namespace: Required: Name and e-mail address.
Recommended: Affiliation, address, etc.
Required: Name and e-mail address. Declaration of syntactic structure:
Recommended: Affiliation, address, etc.
Declaration of syntactic structure: This section should outline any structural features of identifiers
in this namespace. At the very least, this description may be
used to introduce terminology used in other sections. This
structure may also be used for determining realistic
caching/shortcuts approaches; suitable caveats should be provided.
If there are any specific character encoding rules (e.g., which
character should always be used for single-quotes), these should
be listed here.
This section should outline any structural features of Answers might include, but are not limited to:
identifiers in this namespace. At the very least, this
description may be used to introduce terminology used in
other sections. This structure may also be used for
determining realistic caching/shortcuts approaches; suitable
caveats should be provided. If there are any specific
character encoding rules (e.g., which character should
always be used for single-quotes), these should be listed
here.
Answers might include, but are not limited to: - the structure is opaque (no exposition) - a regular expression
for parsing the identifier into components, including naming
authorities
. the structure is opaque (no exposition) Relevant ancillary documentation:
. a regular expression for parsing the identifier into
components, including naming authorities
Relevant ancillary documentation: This section should list any RFCs, standards, or other published
documentation that defines or explains all or part of the
namespace structure.
This section should list any RFCs, standards, or other published Answers might include, but are not limited to:
documentation that defines or explains all or part of the
namespace structure.
Answers might include, but are not limited to: - RFCs outlining syntax of the namespace
- Other of the defining community's (e.g., ISO) documents
outlining syntax of the identifiers in the namespace
- Explanatory material introducing the namespace
. RFCs outlining syntax of the namespace Identifier uniqueness considerations:
. Other of the defining community's (e.g., ISO) documents This section should address the requirement that URN identifiers be
outlining syntax of the identifiers in the namespace assigned uniquely -- they are assigned to at most one resource, and
. Explanatory material introducing the namespace are not reassigned.
Identifier uniqueness considerations: (Note that the definition of "resource" is fairly broad; for example,
information on "Today's Weather" might be considered a single
resource, although the content is dynamic.)
This section should address the requirement that Possible answers include, but are not limited to:
URN identifiers be assigned uniquely -- they are assigned
to at most one resource, and are not reassigned.
(Note that the definition of "resource" is fairly - exposition of the structure of the identifiers, and partitioning
broad; for example, information on "Today's Weather" might of the space of identifiers amongst assignment authorities which
be considered a single resource, although the content is are individually responsible for respecting uniqueness rules
dynamic.) - identifiers are assigned sequentially
- information is withheld; the namespace is opaque
Possible answers include, but are not limited to: Identifier persistence considerations:
. exposition of the structure of the identifiers, and Although non-reassignment of URN identifiers ensures that a URN
partitioning of the space of identifiers amongst will persist in identifying a particular resource even after the
assignment authorities which are individually responsible "lifetime of the resource", some consideration should be given to
for respecting uniqueness rules the persistence of the usability of the URN. This is particularly
. identifiers are assigned sequentially important in the case of URN namespaces providing global
. information is withheld; the namespace is opaque resolution.
Identifier persistence considerations: Possible answers include, but are not limited to:
Although non-reassignment of URN identifiers ensures - quality of service considerations
that a URN will persist in identifying a particular
resource even after the "lifetime of the resource",
some consideration should be given to the persistence
of the usability of the URN. This is particularly
important in the case of URN namespaces providing
global resolution.
Possible answers include, but are not limited to: Process of identifier assignment:
. quality of service considerations This section should detail the mechanisms and/or authorities for
assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how to become an
assigner of identifiers, and/or get one assigned by existing
assignment authorities. Answers could include, but are not
limited to:
Process of identifier assignment: - assignment is completely open, following a particular algorithm
- assignment is delegated to authorities recognized by a
particular organization (e.g., the Digital Object Identifier
Foundation controls the DOI assignment space and its delegation)
- assignment is completely closed (e.g., for a private
organization)
This section should detail the mechanisms and/or authorities Process for identifier resolution:
for assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how
to become an assigner of identifiers, and/or get one
assigned by existing assignment authorities. Answers
could include, but are not limited to:
. assignment is completely open, following a particular If a namespace is intended to be accessible for global resolution,
algorithm it must be registerd in an RDS (Resolution Discovery System, see
. assignment is delegated to authorities recognized by [RFC2276]) such as NAPTR. Resolution then proceeds according to
a particular organization (e.g., the Digital Object standard URI resolution processes, and the mechanisms of the RDS.
Identifier Foundation controls the DOI assignment space and What this section should outline is the requirements for becoming
its delegation) a recognized resolver of URNs in this namespace (and being so-
. assignment is completely closed (e.g., for a private listed in the RDS registry).
organization)
Process for identifier resolution: Answers may include, but are not limited to:
If a namespace is intended to be accessible for global - the namespace is not listed with an RDS; this is not relevant
resolution, it must be registerd in an RDS (Resolution - resolution mirroring is completely open, with a mechanism for
Discovery System, see [RFC2276]) such as NAPTR. Resolution updating an appropriate RDS
then proceeds according to standard URI resolution processes, - resolution is controlled by entities to which assignment has
and the mechanisms of the RDS. What this section should been delegated
outline is the requirements for becoming a recognized resolver
of URNs in this namespace (and being so-listed in the RDS
registry).
Answers may include, but are not limited to: Rules for Lexical Equivalence:
. the namespace is not listed with an RDS; this is not If there are particular algorithms for determining equivalence
relevant between two identifiers in the underlying namespace (hence, in the
. resolution mirroring is completely open, with a mechanism URN string itself), rules can be provided here.
for updating an appropriate RDS
. resolution is controlled by entities to which assignment
has been delegated
Rules for Lexical Equivalence: Some examples include:
If there are particular algorithms for determining - equivalence between hyphenated and non-hyphenated groupings in
equivalence between two identifiers in the underlying the identifier string
namespace (hence, in the URN string itself), rules can - equivalence between single-quotes and double-quotes
be provided here. - Namespace-defined equivalences between specific characters, such
as "character X with or without diacritic marks".
Some examples include: Note that these are not normative statements for any kind of best
practice for handling equivalences between characters; they are
statements limited to reflecting the namespace's own rules.
. equivalence between hyphenated and non-hyphenated Conformance with URN Syntax:
groupings in the identifier string
. equivalence between single-quotes and double-quotes
. Namespace-defined equivalences between specific
characters, such as "character X with or without
diacritic marks".
Note that these are not normative statements for any kind of This section should outline any special considerations required
best practice for handling equivalences between characters; for conforming with the URN syntax. This is particularly
they are statements limited to reflecting the namespace's applicable in the case of legacy naming systems that are used in
own rules. the context of URNs.
Conformance with URN Syntax: For example, if a namespace is used in contexts other than URNs,
it may make use of characters that are reserved in the URN syntax.
This section should flag any such characters, and outline
necessary mappings to conform to URN syntax. Normally, this will
be handled by hex encoding the symbol.
This section should outline any special considerations For example, see the section on SICIs in [RFC2288].
required for conforming with the URN syntax. This is
particularly applicable in the case of legacy naming
systems that are used in the context of URNs.
For example, if a namespace is used in contexts other Validation mechanism:
than URNs, it may make use of characters that are reserved
in the URN syntax. This section should flag any such
characters, and outline necessary mappings to conform to
URN syntax. Normally, this will be handled by hex encoding
the symbol.
For example, see the section on SICIs in [RFC2288]. Apart from attempting resolution of a URN, a URN namespace may
provide mechanism for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN. For
example, even if an ISBN URN namespace is created, it is not clear
that all ISBNs will translate directly into "assigned URNs".
Validation mechanism: A validation mechanims might be:
Apart from attempting resolution of a URN, a URN namespace - a syntax grammar
may provide mechanism for "validating" a URN -- i.e., - an on-line service
determining whether a given string is currently a - an off-line service
validly-assigned URN. For example, even if an ISBN
URN namespace is created, it is not clear that
all ISBNs will translate directly into "assigned URNs".
A validation mechanims might be: Scope:
. a syntax grammar This section should outline the scope of the use of the
. an on-line service identifiers in this namespace. Apart from considerations of
. an off-line service private vs. public namespaces, this section is critical in
evaluating the applicability of a requested NID. For example, a
namespace claiming to deal in "social security numbers" should
have a global scope and address all social security number
structures (unlikely). On the other hand, at a national level, it
is reasonable to propose a URN namespace for "this nation's social
security numbers".
Scope: 4.0 URN Namespace Registration, Update, and NID Assignment Process
This section should outline the scope of the use of the Different levels of disclosure are expected/defined for namespaces.
identifiers in this namespace. Apart from considerations According to the level of open-forum discussion surrounding the
of private vs. public namespaces, this section is critical disclosure, a URN namespace may be assigned or may request a
in evaluating the applicability of a requested NID. For particular identifier. The [RFC2434] document suggests the need to
example, a namespace claiming to deal in "social security specify update mechanisms for registrations -- who is given the
numbers" should have a global scope and address all authority to do so, from time to time, and what are the processes.
social security number structures (unlikely). On the Since URNs are meant to be persistently useful, few (if any) changes
other hand, at a national level, it is reasonable to should be made to the structural interpretation of URN strings (e.g.,
propose a URN namespace for "this nation's social security adding or removing rules for lexical equivalence that might affect
numbers". the interpretation of URN IDs already assigned). However, it may be
important to introduce clarifications, expand the list of authorized
URN assigners, etc, over the natural course of a namespace's
lifetime. Specific processes are outlined below.
4.0 URN Namespace Registration, Update, and NID Assignment Process There are 3 categories of URN namespaces defined here, distinguished
by expected level of service and required procedures for
registration. Furthermore, registration maintenance procedures vary
slightly from one category to another.
Different levels of disclosure are expected/defined for namespaces. I. Experimental: These are not explicitly registered with IANA.
According to the level of open-forum discussion surrounding They take the form
the disclosure, a URN namespace may be assigned or may request a
particular identifier. The [IANA-CONSIDERATIONS] document suggests
the need to specify update mechanisms for registrations -- who
is given the authority to do so, from time to time, and what are
the processes. Since URNs are meant to be persistently useful, few
(if any) changes should be made to the structural interpretation of
URN strings (e.g., adding or removing rules for lexical equivalence that
might affect the interpretation of URN IDs already assigned). However, it
may be important to introduce clarifications, expand the list of
authorized URN assigners, etc, over the natural course of a namespace's
lifetime. Specific processes are outlined below.
There are 3 categories of URN namespaces defined here, distinguished X-<NID>
by expected level of service and required procedures for registration.
Furthermore, registration maintenance procedures vary slightly from
one category to another.
I. Experimental: These are not explicitly registered with IANA. They No provision is made for avoiding collision of experimental
take the form NIDs; they are intended for use within internal or limited
experimental contexts.
x-<NID> As there is no registration, no registration maintenance
procedures are needed.
No provision is made for avoiding collision of experimental II. Informal: These are registered with IANA and are assigned a
NIDs; they are intended for use within internal or limited number sequence as an identifier, in the format:
experimental contexts.
As there is no registration, no registration maintenance "urn-" <number>
procedures are needed.
II. Informal: These are registered with IANA and are assigned a where <number> is chosen by the IANA on a First Come First
number sequence as an identifier, in the format: Served basis (see [RFC2434]).
"urn-" <number> Registrants should send a copy of the registration template
(see section 3.0), duly completed, to the
where <number> is chosen by the IANA on a First Come First urn-nid@apps.ietf.org
Served basis (see [IANA-CONSIDERATIONS]).
Registrants should send a copy of the registration mailing and allow for a 2 week discussion period for
template (see section 3.0), duly completed, to the clarifying the expression of the registration information and
suggestions for improvements to the namespace proposal.
urn-nid@apps.ietf.org After suggestions for clarification of the registration
information have been incorporated, the template may be
submitted to:
iana@iana.org
mailing and allow for a 2 week discussion period for for assignment of a NID.
clarifying the expression of the registration information
and suggestions for improvements to the namespace proposal.
After suggestions for clarification of the registration The only restrictions on <number> are that it consist
information have been incorporated, the template may be strictly of digits and that it not cause the NID to exceed
submitted to: length limitations outlined in the URN syntax ([RFC2168]).
iana@iana.org Registrations may be updated by the original registrant, or
an entity designated by the registrant, by updating the
registration template, submitting it to the discussion list
for a further 2 week discussion period, and finally
resubmitting it to IANA, as described above.
for assignment of a NID. III. Formal: These are processed through an RFC review process.
The RFC need not be standards-track. The template defined in
section 3.0 may be included as part of an RFC defining some
other aspect of the namespace, or it may be put forward as an
RFC in its own right. The proposed template should be sent
to the
The only restrictions on <number> are that it consist urn-nid@apps.ietf.org
strictly of digits and that it not cause the NID to exceed
length limitations outlined in the URN syntax ([RFC2168]).
Registrations may be updated by the original registrant, mailing list to allow for a 2 week discussion period for
or an entity designated by the registrant, by updating clarifying the expression of the registration information,
the registration template, submitting it to the discussion before the IESG progresses the document to RFC status.
list for a further 2 week discussion period, and finally
resubmitting it to IANA, as described above.
III. Formal: These are processed through an RFC review A particular NID string is requested, and is assigned by IETF
process. The RFC need not be standards-track. The consensus (as defined in [RFC2434]), with the additional
template defined in section 3.0 may be included as part constraints that the NID string must
of an RFC defining some other aspect of the namespace, - not be an already-registered NID
or it may be put forward as an RFC in its own right. - not start with "x-" (see Type I above)
The proposed template should be sent to the - not start with "urn-" (see Type II above)
- not start with "XY-", where XY is any combination of 2
ASCII letters (see NOTE, below)
- be more than 2 letters long
urn-nid@apps.ietf.org NOTE: ALL two-letter combinations, and two-letter
combinations followed by "-" and any sequence of valid NID
characters, are reserved for potential use as countrycode-
based NIDs for eventual national registrations of URN
namespaces. The definition and scoping of rules for
allocation of responsibility for such namespaces is beyond
the scope of this document.
mailing list to allow for a 2 week discussion period for Registrations may be updated by updating the RFC through
clarifying the expression of the registration information, standard IETF RFC update mechanisms. Thus, proposals for
before the IESG progresses the document to RFC status. updates may be made by the original authors, other IETF
participants, or the IESG. In any case, the proposed updated
template must be circulated on the urn-nid discussion list,
allowing for a 2 week review period.
A particular NID string is requested, and is assigned by IETF URN namespace registrations will be posted in the anonymous FTP
consensus (as defined in [IANA-CONSIDERATIONS]), with directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-
the additional constraints that the NID string must namespaces/".
. not be an already-registered NID 5.0 Example
. not start with "x-" (see Type I above)
. not start with "urn-" (see Type II above)
. not start with "XY-", where XY is any
combination of 2 ASCII letters (see NOTE, below)
. be more than 2 letters long
NOTE: ALL two-letter combinations, and two-letter combinations The following example is provided for the purposes of illustration of
followed by "-" and any sequence of valid NID characters, are the URN NID template described in section 3.0. Although it is based
reserved for potential use as countrycode-based NIDs for on a hypothetical "generic Internet namespace" that has been
eventual national registrations of URN namespaces. The discussed informally within the URN WG, there are still technical and
definition and scoping of rules for allocation of responsibility infrastructural issues that would have to be resolved before such a
for such namespaces is beyond the scope of this document. namespace could be properly and completely described.
Registrations may be updated by updating the RFC through Namespace ID:
standard IETF RFC update mechanisms. Thus, proposals for To be assigned
updates may be made by the original authors, other IETF
participants, or the IESG. In any case, the proposed
updated template must be circulated on the urn-nid
discussion list, allowing for a 2 week review period.
URN namespace registrations will be posted in the anonymous FTP directory Registration Information:
"ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/".
5.0 Example Version 1
Date: <when submitted>
The following example is provided for the purposes of illustration of Declared registrant of the namespace:
the URN NID template described in section 3.0. Although it is based on
a hypothetical "generic Internet namespace" that has been discussed informally
within the URN WG, there are still technical and infrastructural issues
that would have to be resolved before such a namespace could be properly
and completely described.
Namespace ID: Required: Name and e-mail address.
Recommended: Affiliation, address, etc.
To be assigned Declared registrant of the namespace:
Registration Information: Name: T. Cat
E-mail: leslie@thinkingcat.com
Affiliation: Thinking Cat Enterprises
Address: 1 ThinkingCat Way
Trupville, NewCountry
Version 1 Declaration of structure:
Date: <when submitted>
Declared registrant of the namespace: The identifier structure is as follows:
Required: Name and e-mail address. URN:<assigned number>:<FQDN>:<assigned US-ASCII string>
Recommended: Affiliation, address, etc.
Declared registrant of the namespace: where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements.
Name: T. Cat Relevant ancillary documentation:
E-mail: leslie@thinkingcat.com
Affiliation: Thinking Cat Enterprises
Address: 1 ThinkingCat Way
Trupville, NewCountry
Declaration of structure: Definition of domain names, found in:
The identifier structure is as follows: P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987.
URN:<assigned number>:<FQDN>:<assigned US-ASCII string> Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned string is never
reassigned for a given FQDN, and that the FQDN is never
reassigned.
where FQDN is a fully-qualified domain name, and the N.B.: operationally, there is nothing that prevents a domain name
assigned string is conformant to URN syntax requirements. from being reassigned; indeed, it is not an uncommon occurrence.
This is one of the reasons that this example makes a poor URN
namespace in practice, and is therefore not seriously being
proposed as it stands.
Identifier persistence considerations:
Relevant ancillary documentation: Persistence of identifiers is dependent upon suitable delegation
of resolution at the level of "FQDN"s, and persistence of FQDN
assignment.
Definition of domain names, found in: Same note as above.
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", Process of identifier assignment:
RFC1035, November 1987.
Identifier uniqueness considerations: Assignment of these URNs delegated to individual domain name
holders (for FQDNs). The holder of the FQDN registration is
required to maintain an entry (or delegate it) in the NAPTR RDS.
Within each of these delegated name partitions, the string may be
assigned per local requirements.
Uniqueness is guaranteed as long as the assigned e.g. urn:<assigned number>:thinkingcat.com:001203
string is never reassigned for a given FQDN, and that the FQDN
is never reassigned.
N.B.: operationally, there is nothing that prevents a domain Process for identifier resolution:
name from being reassigned; indeed, it is not an uncommon
occurrence. This is one of the reasons that this example
makes a poor URN namespace in practice, and is therefore not
seriously being proposed as it stands.
Identifier persistence considerations: Domain name holders are responsible for operating or delegating
resolution servers for the FQDN in which they have assigned URNs.
Persistence of identifiers is dependent upon suitable Rules for Lexical Equivalence:
delegation of resolution at the level of "FQDN"s, and persistence
of FQDN assignment.
Same note as above. FQDNs are case-insensitive. Thus, the portion of the URN
Process of identifier assignment: urn:<assigned number>:<FQDN>:
Assignment of these URNs delegated to individual domain is case-insenstive for matches. The remainder of the identifier
name holders (for FQDNs). The holder of the FQDN registration must be considered case-sensitve.
is required to maintain an entry (or delegate it) in the
NAPTR RDS. Within each of these delegated name partitions,
the string may be assigned per local requirements.
e.g. urn:<assigned number>:thinkingcat.com:001203 Conformance with URN Syntax:
Process for identifier resolution: No special considerations.
Domain name holders are responsible for operating or Validation mechanism:
delegating resolution servers for the FQDN in which they
have assigned URNs.
Rules for Lexical Equivalence: None specified.
FQDNs are case-insensitive. Thus, the portion of the URN Scope:
urn:<assigned number>:<FQDN>: Global.
is case-insenstive for matches. The remainder of the identifier 6.0 Security Considerations
must be considered case-sensitve.
Conformance with URN Syntax: This document largely focuses on providing mechanisms for the
declaration of public information. Nominally, these declarations
should be of relatively low security profile, however there is always
the danger of "spoofing" and providing mis-information. Information
in these declarations should be taken as advisory.
No special considerations. 7.0 References
Validation mechanism: [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System", RFC
2168, June 1997.
None specified. [RFC2169] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
Scope: [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange
formats - Information interchange - Representation of
dates and times"
Global. [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998.
6.0 Security Considerations [NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS URI
Resolution", Work in Progress.
This document largely focuses on providing mechanisms for the [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
declaration of public information. Nominally, these declarations
should be of relatively low security profile, however there is
always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory.
7.0 References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Resource Identifiers using the Domain Name System", RFC 2168, Uniform Resource Names", RFC 1737, December 1994.
June 1997.
[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN [RFC2276] Sollins, K., "Architectural Principles of Uniform
Resolution", RFC 2169, June 1997. Resource Name Resolution", RFC 2276, January 1998.
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - 8.0 Authors' Addresses
Information interchange - Representation of dates and times"
[RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing Leslie L. Daigle
Bibliographic Identifiers as Uniform Resource Names", RFC 2288, Thinking Cat Enterprises
February 1998.
[NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution EMail: leslie@thinkingcat.com
using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt.
[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. Dirk-Willem van Gulik
ISIS/STA/CEO - TP 270
Joint Research Centre Ispra
21020 Ispra (Va)
Italy.
[IANA-CONSIDERATIONS] T. Narten and H. Alvestrand, "Guidelines for Phone: +39 332 78 9549 or 5044
Writing an IANA Considerations Section in RFCs", Fax: +39 332 78 9185
draft-iesg-iana-considerations-06.txt. EMail: Dirk.vanGulik@jrc.it
[RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements Renato Iannella
for Uniform Resource Names", RFC1737, December 1994 DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource Phone: +61 7 3365 4310
Name Resolution", RFC 2276, January 1998. Fax: +61 7 3365 4311
EMail: renato@dstc.edu.au
8.0 Authors' Addresses Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN
Leslie L. Daigle Phone: +46-5626 4000
Bunyip Information Systems Inc Fax: +46-5626 4200
147 St. Paul St. West EMail: paf@swip.net
Suite 200
Montreal, Quebec, CANADA
H2Y 1Z5
voice: +1 514 285-0088
fax: +1 514 285-4515
email: leslie@bunyip.com
Dirk-Willem van Gulik 9.0 Full Copyright Statement
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 Copyright (C) The Internet Society (1999). All Rights Reserved.
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 This document and translations of it may be copied and furnished to
Tele2/Swipnet others, and derivative works that comment on or otherwise explain it
Borgarfjordsgatan 16 or assist in its implementation may be prepared, copied, published
P.O. Box 62 and distributed, in whole or in part, without restriction of any
S-164 94 Kista kind, provided that the above copyright notice and this paragraph are
SWEDEN included on all such copies and derivative works. However, this
voice: +46-5626 4000 document itself may not be modified in any way, such as by removing
fax: +46-5626 4200 the copyright notice or references to the Internet Society or other
email: paf@swip.net Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 153 change blocks. 
444 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/