| URNBIS | P. Saint-Andre, Ed. |
| Internet-Draft | Cisco Systems, Inc. |
| Obsoletes: 3406 (if approved) | L. Daigle |
| Intended status: Best Current Practice | Thinking Cat Enterprises |
| Expires: August 23, 2013 | D.W. van Gulik |
| R. Iannella | |
| Semantic Identity | |
| P. Faltstrom | |
| Netnod | |
| February 19, 2013 |
Uniform Resource Name (URN) Namespace Definition Mechanisms
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05
This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 23, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a Uniform Resource Identifier (URI) [RFC3986] that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme.
This document supplements the Uniform Resource Name (URN) syntax specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining (1) the concept of a URN namespace, (2) a mechanism for defining such namespaces and associating each namespace with a public identifier (called a Namespace ID or "NID"), and (3) procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA).
This document rests on two key assumptions:
URN namespaces were originally defined in [RFC2611], which was obsoleted by [RFC3406]. Based on experience with defining and registering URN namespaces since that time, this document specifies URN namespaces with the smallest reasonable set of changes from [RFC3406]. If approved, this document will obsolete RFC 3406.
The discussion venue for this document is mailing list of the URNBIS WG; visit https://www.ietf.org/mailman/listinfo/urn for subscription and archive information.
Several important terms used in this document are defined in the URN syntax specification [I-D.ietf-urnbis-rfc2141bis-urn].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
For the purposes of URNs, a "namespace" is a collection of unique identifiers that are consistently assigned according to a common definition.
The uniqueness constraint means that an identifier within the namespace is never assigned to more than one resource and never re-assigned to a different resource (however, a single resource can have more than one URN assigned to it for different purposes).
The consistent assignment constraint means that an identifier within the namespace is assigned by an organization or in accordance with a process that is always followed (e.g., in the form of an algorithm).
The common definition constraint means that the syntax for identifiers within the namespace and the process for assigning such identifiers are clearly defined in a specification.
A URN namespace is identified by a particular designator (which syntactically follows the 'urn' scheme name) in order to:
With regard to global uniqueness, using different designators for different collections of identifiers ensures that no two URNs will be the same for different resources (since each collection is required to uniquely assign each identifier). For instance, some identifier systems use strings of numbers as identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that some numbers might be valid identifiers in two different established identifier systems, where the namespace identifier differentiates between the resulting URNs.
With regard to the structure of URNs assigned within a namespace, 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 identifiers, 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., a publishing community, an association of booksellers, developers of particular application protocols, etc.); therefore these issues are beyond the scope of URN syntax and the rules regarding URN namespaces in general.
URN namespaces inherit certain rights and responsibilities, including:
There are two types of URN namespace: formal and informal. These are distinguished by the expected level of service, the information necessary to define the namespace, and the procedures for registration. To date, the vast majority of the registered namespaces have been formal, so this document concentrates on formal namespaces.
Note: [RFC3406] defined a third type of "experimental namespaces:, denoted by prefixing the namespace identifier with the string "X-". Consistent with [RFC6648], this specification removes the experimental category.
A formal namespace can be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to some subset of users on the Internet. That is, a formal NID proposal, if accepted, needs to be functional on and with the global Internet, not limited to users in communities or networks not connected to the Internet. For example, consider a NID that is meant for naming of physics research; if that NID request effectively forced someone to use a proprietary network or service that was not at all open to the general Internet user, then it would make a poor request for a formal NID. The intent is that, while the community of those who might actively use the names assigned within that NID might be small (but no less important), the potential use of names within that NID is open to any user on the Internet.
It is expected that formal NIDs might be applied to namespaces where some aspects are not fully open. For example, a namespace might make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the namespace. However, it might still provide benefit to some Internet users if the services associated have openly-published access protocols.
In addition to the basic information specified in the namespace definition template (see Section 8), a formal namespace request needs to be accompanied by documented considerations of the need for a new namespace and of the community benefit from formally establishing the proposed URN namespace.
Additionally, since the goal of URNs is to provide persistent identification, a formal namespace request needs to give some consideration as to the longevity and maintainability of the namespace. Possible factors to consider with regard to an organization that will assign URNs within a namespace include the following:
Informal namespaces are full-fledged URN namespaces, with all the rights and responsibilities associated thereto. Informal namespaces differ from formal namespaces in the process for assigning a NID: IANA will assign an alphanumeric NID (e.g., "urn-7") to informal namespaces, per the process outlined under Section 7.
A URN namespace is defined by the following factors:
Processes for resolution of URNs assigned within a namespace (if any) are out of scope for this document. The following sections provide guidelines for (1) defining the syntax of URNs within a namespace and (2) specifying how URNs will be assigned within a namespace.
Formal NIDs are assigned as a result of IETF Review as defined in the "IANA Considerations" document [RFC5226]. Thus an application for a formal NID is made by publishing an RFC in the IETF stream, either as the product of an IETF working group or as an individual submission sponsored by an Area Director. The RFC need not be standards track (indeed, to date most RFCs registering URN namespaces have been informational), but it will be subject to IESG review and approval pursuant to the guidelines provided here (as well as standard RFC publication guidelines).
A formal namespace registration requests a particular NID, subject to the following constraints:
All two-letter combinations, and all 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 countrycode-based namespaces is beyond the scope of this document.
The specification defining a formal namespace MUST include a completed namespace definition template (see Section 8).
The specification also MUST include the following sections.
The "Namespace Considerations" section outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements). Potential considerations include:
It is expected that more than one namespace might serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration.
The "Community Considerations" section explains how the intended community will benefit by assignment of this namespace as well as how a general Internet user will be able to use the space if they care to do so. Potential considerations include:
The "IANA Considerations" section indicates that the document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs.
Informal namespaces are directly requested of IANA and are assigned based on a policy of First Come First Served [RFC5226].
The namespace identifier assigned by IANA has the following syntax:
"urn-" <number>
The <number> is chosen by IANA. The only restrictions on <number> are that it (1) consist strictly of ASCII digits and (2) not cause the NID to exceed the length limitations defined in the URN syntax specification [I-D.ietf-urnbis-rfc2141bis-urn].
The registration policy for formal namespaces is IETF Review [RFC5226]. The key steps for registration of a formal namespace are:
A registration can be revised by updating the RFC through normal IETF processes [RFC2606]. The authors of the revised document need to follow the same steps outlined above for new registrations.
The registration policy for formal namespaces is First Come First Served [RFC5226]. The key steps for registration of an informal namespace are:
Informal namespaces can also be revised by updating the template and processing it as outlined above for new registrations.
Definition of a URN namespace is accomplished by completing the following template. In addition to providing a mechanism for defining the structure of URNs assigned within the namespace, this information is designed to be useful for:
This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own.
As described under Section 6.1.2, applications for formal URN namespaces MUST also document "Namespace Considerations", "Community Considerations" and "IANA Considerations".
The information to be provided in the template is as follows:
Namespace ID:
Requested of IANA (formal) or assigned by IANA (informal).
Registration Information:
The version and date of the registration:
- Registration version number: starting with 1,
incrementing by 1 with each new version
- Registration date: date submitted to the IANA, using the
format YYYY-MM-DD
Declared registrant of the namespace:
This includes:
- Registering organization
Name
Address
- Designated contact person
Name
Contact information
(at least one of email address,
phone number, postal address)
Declaration of syntactic structure:
This section ought to outline any structural features of
identifiers in this namespace. At the very least, this
description can be used to introduce terminology used in
other sections. This structure can also be used for
determining realistic caching/shortcuts approaches;
suitable caveats ought to be provided. If there are any
specific character encoding rules (e.g., which character
ought to always be used for single-quotes), these ought
to 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
Relevant ancillary documentation:
This section ought to list any RFCs, standards, or other
published 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
Identifier uniqueness considerations:
This section ought to address the requirement that URNs are
assigned uniquely -- i.e., they are assigned to at most one
resource, and are not reassigned.
(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.)
Possible answers include, but are not limited to:
- Exposition of the structure of the identifiers, and
partitioning of the space of identifiers amongst assignment
authorities which are individually responsible for
respecting uniqueness rules
- Identifiers are assigned sequentially
- Information is withheld; the namespace is opaque
Identifier persistence considerations:
Although non-reassignment of URN identifiers ensures that a URN
will persist in identifying a particular resource even after
the "lifetime of the resource", some consideration ought to 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:
- Quality of service considerations
Process of identifier assignment:
This section ought to detail the mechanisms and/or authorities
for assigning URNs to resources. It ought to make clear whether
assignment is completely open or, if limited, how to become an
assigner of identifiers or how to get an identifer assigned by
existing assignment authorities.
Answers could include, but are not limited to:
- 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)
Process for identifier resolution:
If a namespace is intended to be accessible for global
resolution, it needs to be registered in an RDS (Resolution
Discovery System, see RFC 2276) such as DDDS. Resolution
then proceeds according to standard URI resolution processes,
and the mechanisms of the RDS. What this section ought to
outline is the requirements for becoming a recognized resolver
of URNs in this namespace (and being so- listed in the RDS
registry).
Answers might include, but are not limited to:
- The namespace is not listed with an RDS; therefore this
section is not applicable
- Resolution mirroring is completely open, with a mechanism
for updating an appropriate RDS
- Resolution is controlled by entities to which assignment
has been delegated
Rules for Lexical Equivalence:
If there are particular algorithms for determining equivalence
between two identifiers in the underlying namespace (hence, in
the URN string itself), rules can be provided here.
Some examples include:
- Equivalence between hyphenated and non-hyphenated 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
best practice for handling equivalences between characters;
they are statements limited to reflecting the namespace's
own rules.
Conformance with URN Syntax:
This section ought to outline any special considerations
necessary 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 than URNs,
it might make use of characters that are reserved in the URN
syntax.
This section ought to flag any such characters, and outline
necessary mappings to conform to URN syntax. Normally, this
will be handled by hex-encoding the symbol as specified in
RFC 3986.
Validation mechanism:
Apart from attempting resolution of a URN, a URN namespace may
provide mechanisms for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN.
There are two issues here: 1) users ought not "guess" URNs in
a namespace; 2) when the URN namespace is based on an existing
identifier system, it might not be the case that all existing
identifiers are assigned on Day 0. The reasonable expectation
is that the resource associated with each resulting URN is
somehow related to the thing identified by the original
identifier system, but those resources might not exist for each
original identifier. For example, even if a URN namespace were
defined based on telephone numbers, it is not clear that all
telephone numbers would immediately become "valid" URNs, that
could be resolved using whatever mechanisms are described as
part of the namespace registration.
Validation mechanisms might be:
- A syntax grammar
- An on-line service
- An off-line service
Scope:
This section ought to outline the scope of the use of the
identifiers in this namespace. Apart from considerations of
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"
ought to 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".
This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations will be of relatively low security profile, however there is always the danger of "spoofing" and providing mis-information. Information in these declarations ought to be taken as advisory.
This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA ought to assign the appropriate NID (formal or informal) once the procedures outlined in this document have been completed.
| [I-D.ietf-urnbis-rfc2141bis-urn] | Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN) Syntax", Internet-Draft draft-ietf-urnbis-rfc2141bis-urn-04, November 2013. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [RFC2606] | Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. |
| [RFC2611] | Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999. |
| [RFC3406] | Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. |
| [RFC6648] | Saint-Andre, P., Crocker, D. and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012. |
Although on the surface it might appear that this document is significantly different from [RFC3406], in general it only modifies the order of presentation, with the intent of making it easier for interested parties to define and register URN namespaces. In addition, some of the text was updated to be consistent with the definition of Uniform Resource Identifiers (URIs) [RFC3986] and the processes for registering information with the IANA [RFC5226]. The only major substantive change was removing the category of experimental namespaces, consistent with [RFC6648].