Skip to main content

6. Defining and Registering a URN Namespace

6.1. Overview​

Because the space of URN namespaces is itself managed, the definition of a URN namespace SHOULD pay particular attention to:

  1. The purpose of the URN namespace.

  2. The syntax of URNs assigned within the URN namespace, including the internal syntax and anticipated effects of r-components or q-components. (The syntax and interpretation of f-components are defined in RFC 3986.)

  3. The process for assigning URNs within the URN namespace.

  4. The security implications of assigning URNs within the URN namespace and of using the assigned URNs.

  5. Any potential interoperability issues with URNs assigned within the URN namespace.

  6. Optionally, the process for resolving URNs assigned within the URN namespace.

The section on completing the template (Section 6.4) explains these matters in greater detail. Although the registration templates are the same in all cases, slightly different procedures are used depending on the source of the registration.

6.2. Registration Policy and Process: Community Registrations​

The basic registration policy for URN namespaces is Expert Review as defined in the IANA Considerations document [RFC5226]. For URN namespaces or their definitions that are intended to become standards or constituent parts of standards, the output of the Expert Review process is intended to be a report rather than instructions to IANA to take action (see below). The key steps are:

  1. Fill out the URN namespace registration template (see Section 6.4 and Appendix A). This can be done as part of an Internet-Draft or a specification in another series, although that is not a requirement.

  2. Send the completed template to the [email protected] discussion list for review.

  3. If necessary to address comments received, repeat steps 1 and 2.

  4. If the Designated Experts approve the request and no standardization action is involved, the IANA will register the requested NID. If standardization is anticipated, the Designated Experts will prepare a report and forward it to the appropriate standards approval body (the IESG in the case of the IETF); IANA will register the requested NID only after receiving directions from that body and a copy of the Expert Review report.

A URN namespace registration can be revised by updating the registration template, following the same steps outlined above for new registrations. A revised registration MUST describe differences from prior versions and SHOULD make special note of any relevant changes in the underlying technologies or URN namespace management processes.

Experience to date with URN namespace registration requests has shown that registrants sometimes do not initially understand some of the subtleties of URN namespaces and that defining the URN namespace in the form of a specification enables the registrants to clearly formulate their "contract" with the intended user community. Therefore, although the registration policy for formal URN namespaces is Expert Review and a specification (as distinct from the registration template) is not strictly required, registrants SHOULD provide a stable specification documenting the URN namespace definition and expanding upon the issues described herein.

Because naming can be difficult and contentious, URN namespace registrants and the Designated Experts are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus (see [RFC7282]) on handling registration requests. They are also encouraged to bring additional expertise into the discussion if that would be helpful in providing perspective or otherwise resolving issues.

Especially when iterations in the registration process are prolonged, Designated Experts are expected to take reasonable precautions to avoid "race conditions" on proposed NIDs and, if such situations arise, to encourage applicants to work out any conflicts among themselves.

6.3. Registration Policy and Process: Fast Track for Standards Development Organizations, Scientific Societies, and Similar Bodies​

The IETF recognizes that situations will arise in which URN namespaces will be created to either embed existing and established standards, particularly identifier standards, or reflect knowledge, terminology, or methods of organizing information that lie well outside the IETF's scope or the likely subject matter knowledge of its Designated Experts. In situations in which the registration request originates from, or is authorized by, a recognized standards development organization, scientific society, or their designees, a somewhat different procedure is available at the option of that body:

  1. The URN namespace registration template is filled out and submitted as in steps 1 and 2 of Section 6.2.

  2. A specification is required that reflects or points to the needed external standards or specifications. Publication in the RFC Series or through an IETF process (e.g., posting as an Internet- Draft) is not expected and would be appropriate only under very unusual circumstances.

  3. The reviews on the discussion list and by the Designated Experts are strictly advisory, with the decisions about what advice to accept and the length of time to allocate to the process strictly under the control of the external body.

  4. When that body concludes that the application is sufficiently mature, its representative(s) will request that IANA complete the registration for the NID, and IANA will do so.

Decisions about whether to recognize the requesting entity as a standards development organization or scientific society are the responsibility of the IESG.

A model similar to this has already been defined for recognized standards development organizations that wish to register media types. The document describing that mechanism [RFC6838] provides somewhat more information about the general approach.

6.4. Completing the Template​

A template for defining and registering a URN namespace is provided in Appendix A. This section describes considerations for completing the template.

6.4.1. Purpose​

The "Purpose" section of the template describes matters such as:

  1. The kinds of resources identified by URNs assigned within the URN namespace.

  2. The scope and applicability of the URNs assigned within the URN namespace; this might include information about the community of use (e.g., a particular nation, industry, technology, or organization), whether the assigned URNs will be used on public networks or private networks, etc.

  3. How the intended community (and the Internet community at large) will benefit from using or resolving the assigned URNs.

  4. How the URN namespace relates to and complements existing URN namespaces, URI schemes, and non-URN identifier systems.

  5. The kinds of software applications that can use or resolve the assigned URNs (e.g., by differentiating among disparate URN namespaces, identifying resources in a persistent fashion, or meaningfully resolving and accessing services associated with the URN namespace).

  6. Whether resolution services are available or will be available (and, if so, the nature or identity of the services). Examples of q-component and (when they are standardized) r-component semantics and syntax are helpful here, even if detailed definitions are provided elsewhere or later.

  7. Whether the URN namespace or its definition is expected to become a constituent part of a standard being developed in the IETF or some other recognized standards body.

6.4.2. Syntax​

The "Syntax" section of the template contains:

  1. A description of the structure of URNs within the URN namespace, in conformance with the fundamental URN syntax. The structure might be described in terms of a formal definition (e.g., using ABNF [RFC5234]), an algorithm for generating conformant URNs, or a regular expression for parsing the name into constituent parts; alternatively, the structure might be opaque.

  2. Any special character encoding rules for assigned URNs (e.g., which character ought to always be used for quotes).

  3. Rules for determining URN-equivalence between two names in the URN namespace. Such rules ought to always have the effect of eliminating false negatives that might otherwise result from comparison. If it is appropriate and helpful, reference can be made to particular equivalence rules defined in the URI specification [RFC3986] or to Section 3 of this document. Examples of URN-equivalence rules include equivalence between uppercase and lowercase characters in the NSS, between hyphenated and non-hyphenated groupings in the name, or between single quotes and double quotes. There may also be namespace-specific special encoding considerations, especially for URNs that contain embedded forms of names from non-URN identifier systems. (Note that these are not normative statements for any kind of best practice related to handling of relationships between characters in general; such statements are limited to one particular URN namespace only.)

  4. Any special considerations necessary for conforming with the URN syntax. This is particularly applicable in the case of existing, non-URN identifier systems that are used in the context of URNs. For example, if a non-URN identifier system is used in contexts other than URNs, it might make use of characters that are reserved in the URN syntax. This section ought to note any such characters and outline necessary mappings to conform to URN syntax. Normally, this will be handled by percent-encoding the character as specified in Section 2.1 of the URI specification [RFC3986] and as discussed in Section 1.2.2 of this specification.

  5. Any special considerations for the meaning of q-components (e.g., keywords) or f-components (e.g., predefined terms) in the context of this URN namespace.

6.4.3. Assignment​

The "Assignment" section of the template describes matters such as:

  1. Mechanisms or authorities for assigning URNs to resources. It ought to make clear whether assignment is completely open (e.g., following a particular procedure such as first-come, first-served (FCFS)), completely closed (e.g., for a private organization), or limited in various ways (e.g., delegated to authorities recognized by a particular organization); if limited, it ought to explain how to become an assigner of names or how to request assignment of names from existing assignment authorities.

  2. Methods for ensuring that URNs within the URN namespace are unique. For example, names might be assigned sequentially or in accordance with some well-defined process by a single authority, assignment might be partitioned among delegated authorities that are individually responsible for respecting uniqueness rules, or URNs might be created independently following an algorithm that itself guarantees uniqueness.

6.4.4. Security and Privacy​

The "Security and Privacy" section of the template describes any potential issues related to security and privacy with regard to assignment, use, and resolution of names within the URN namespace. Examples of such issues include:

  • The consequences of producing false negatives and false positives during comparison for URN-equivalence (see Section 3.1 of this specification and "Issues in Identifier Comparison for Security Purposes" [RFC6943]).

  • Leakage of private information when names are communicated on the public Internet.

  • The potential for directory harvesting.

  • Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. In particular, note the privacy considerations text for the Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) namespace [RFC7254], which may provide a useful model for such cases.

6.4.5. Interoperability​

The "Interoperability" section MUST specify any known potential issues related to interoperability. Examples include possible confusion with other URN namespaces, non-URN identifier systems, or URI schemes because of syntax (e.g., percent-encoding of certain characters) or scope (e.g., overlapping areas of interest). If at all possible, concerns that arise during the registration of a URN namespace (e.g., due to the syntax or scope of a non-URN identifier system) should be resolved as part of or in parallel to the registration process.

6.4.6. Resolution​

The "Resolution" section MUST specify whether resolution mechanisms are intended or anticipated for URNs assigned within the URN namespace.

If resolution is intended, then this section SHOULD specify whether the organization that assigns URNs within the URN namespace intends to operate or recommend any resolution services for URNs within that URN namespace. In addition, if the assigning organization intends to implement registration for publicly advertised resolution services (for example, using a system developed in the spirit of the original architectural principles and service descriptions for URN resolution [RFC2276] [RFC2483]), then this section SHOULD list or reference the requirements for being publicly advertised by the assigning organization. In addition, this section SHOULD describe any special considerations for the handling of r-components in the context of this URN namespace.

6.4.7. Additional Information​

The "Additional Information" section includes information that would be useful to those trying to understand this registration or its relationship to other registrations, such as comparisons to existing URN namespaces that might seem to overlap.

This section of the template is optional.