diff options
Diffstat (limited to 'doc/rfc/rfc8141.txt')
| -rw-r--r-- | doc/rfc/rfc8141.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc8141.txt b/doc/rfc/rfc8141.txt new file mode 100644 index 0000000..0fb5179 --- /dev/null +++ b/doc/rfc/rfc8141.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Saint-Andre +Request for Comments: 8141 Filament +Obsoletes: 2141, 3406 J. Klensin +Category: Standards Track April 2017 +ISSN: 2070-1721 + + + Uniform Resource Names (URNs) + +Abstract + + A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) + that is assigned under the "urn" URI scheme and a particular URN + namespace, with the intent that the URN will be a persistent, + location-independent resource identifier. With regard to URN syntax, + this document defines the canonical syntax for URNs (in a way that is + consistent with URI syntax), specifies methods for determining URN- + equivalence, and discusses URI conformance. With regard to URN + namespaces, this document specifies a method for defining a URN + namespace and associating it with a namespace identifier, and it + describes procedures for registering namespace identifiers with the + Internet Assigned Numbers Authority (IANA). This document obsoletes + both RFCs 2141 and 3406. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8141. + + + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 1] + +RFC 8141 URNs April 2017 + + +Copyright Notice + + Copyright (c) 2017 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 2] + +RFC 8141 URNs April 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 6 + 1.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 8 + 1.2.2. Character Sets and Encodings . . . . . . . . . . . . 9 + 2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.1. Namespace Identifier (NID) . . . . . . . . . . . . . . . 10 + 2.2. Namespace Specific String (NSS) . . . . . . . . . . . . . 10 + 2.3. Optional Components . . . . . . . . . . . . . . . . . . . 12 + 2.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 12 + 2.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 13 + 2.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 15 + 3. URN-Equivalence . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 18 + 4.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.3. URNs and Relative References . . . . . . . . . . . . . . 19 + 4.4. Transport and Display . . . . . . . . . . . . . . . . . . 19 + 4.5. URI Design and Ownership . . . . . . . . . . . . . . . . 20 + 5. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.1. Formal URN Namespaces . . . . . . . . . . . . . . . . . . 22 + 5.2. Informal URN Namespaces . . . . . . . . . . . . . . . . . 23 + 6. Defining and Registering a URN Namespace . . . . . . . . . . 24 + 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.2. Registration Policy and Process: Community Registrations 25 + 6.3. Registration Policy and Process: Fast Track for Standards + Development Organizations, Scientific Societies, and + Similar Bodies . . . . . . . . . . . . . . . . . . . . . 26 + 6.4. Completing the Template . . . . . . . . . . . . . . . . . 27 + 6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 27 + 6.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 29 + 6.4.4. Security and Privacy . . . . . . . . . . . . . . . . 29 + 6.4.5. Interoperability . . . . . . . . . . . . . . . . . . 30 + 6.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 30 + 6.4.7. Additional Information . . . . . . . . . . . . . . . 30 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 31 + 7.2. Registration of URN Namespaces . . . . . . . . . . . . . 31 + 7.3. Discussion List for New and Updated NID Registrations . . 31 + 8. Security and Privacy Considerations . . . . . . . . . . . . . 32 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 9.2. Informative References . . . . . . . . . . . . . . . . . 32 + + + +Saint-Andre & Klensin Standards Track [Page 3] + +RFC 8141 URNs April 2017 + + + Appendix A. Registration Template . . . . . . . . . . . . . . . 37 + Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 38 + B.1. Syntax Changes from RFC 2141 . . . . . . . . . . . . . . 38 + B.2. Other Changes from RFC 2141 . . . . . . . . . . . . . . . 39 + Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 39 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + +1. Introduction + + A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) + [RFC3986] that is assigned under the "urn" URI scheme and a + particular URN namespace, with the intent that the URN will be a + persistent, location-independent resource identifier. A URN + namespace is a collection of such URNs, each of which is (1) unique, + (2) assigned in a consistent and managed way, and (3) assigned + according to a common definition. (Some URN namespaces create names + that exist only as URNs, whereas others assign URNs based on names + that were already created in non-URN identifier systems, such as + ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].) + + The assignment of URNs is done by an organization (or, in some cases, + according to an algorithm or other automated process) that has been + formally delegated a URN namespace within the "urn" scheme (e.g., a + URN in the "example" URN namespace [RFC6963] might be of the form + "urn:example:foo"). + + This document rests on two key assumptions: + + 1. Assignment of a URN is a managed process. + + 2. The space of URN namespaces is itself managed. + + While other URI schemes may allow resource identifiers to be freely + chosen and assigned, such is not the case for URNs. The syntactical + correctness of a name starting with "urn:" is not sufficient to make + it a URN. In order for the name to be a valid URN, the namespace + identifier (NID) needs to be registered in accordance with the rules + defined here, and the remaining parts of the assigned-name portion of + the URN need to be generated in accordance with the rules for the + registered URN namespace. + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 4] + +RFC 8141 URNs April 2017 + + + So that information about both URN syntax and URN namespaces is + available in one place, this document does the following: + + 1. Defines the canonical syntax for URNs in general (in a way that + is consistent with URI syntax), specifies methods for determining + URN-equivalence, and discusses URI conformance. + + 2. Specifies a method for defining a URN namespace and associating + it with a particular NID, and describes procedures for + registering URN NIDs with the Internet Assigned Numbers Authority + (IANA). + + For URN syntax and URN namespaces, this document modernizes and + replaces the original specifications for URN syntax [RFC2141] and for + the definition and registration of URN namespaces [RFC3406]. These + modifications build on the key requirements provided in the original + functional description for URNs [RFC1737] and on the lessons of many + years of experience. In those original documents and in the present + one, the intent is to define URNs in a consistent manner so that, + wherever practical, the parsing, handling, and resolution of URNs can + be independent of the URN namespace within which a given URN is + assigned. + + Together with input from several key user communities, the history + and experiences with URNs dictated expansion of the URN definition to + support new functionality, including the use of syntax explicitly + reserved for future standardization in RFC 2141. All URN namespaces + and URNs that were valid under the earlier specifications remain + valid, even though it may be useful to update the definitions of some + URN namespaces to take advantage of new features. + + The foregoing considerations, together with various differences + between URNs and URIs that are locators (specifically URLs) as well + as the greater focus on URLs in RFC 3986 as the ultimate successor to + [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 + and this specification that appear (or perhaps actually are) not + completely consistent, especially with regard to actions or semantics + other than the basic syntax itself. If such situations arise, + discussions of URNs and URN namespaces should be interpreted + according to this document and not by extrapolation from RFC 3986. + + Summaries of changes from RFCs 2141 and 3406 appear in Appendices B + and C, respectively. This document obsoletes both [RFC2141] and + [RFC3406]. While it does not explicitly update or replace [RFC1737] + or [RFC2276], the reader who references those documents should be + aware that the conceptual model of URNs in this document is slightly + different from those older specifications. + + + + +Saint-Andre & Klensin Standards Track [Page 5] + +RFC 8141 URNs April 2017 + + +1.1. Terminology + + The following terms are distinguished from each other as described + below: + + URN: A URI (as defined in RFC 3986) using the "urn" scheme and with + the properties of a "name" as described in that document as well + as the properties described in this one. The term applies to the + entire URI including its optional components. Note to the reader: + the term "URN" has been used in other contexts to refer to a URN + namespace, the namespace identifier, the assigned-name, and URIs + that do not use the "urn" scheme. All but the last of these is + described using more specific terminology elsewhere in this + document, but, because of those other uses, the term should be + used and interpreted with care. + + Locator: An identifier that provides a means of accessing a + resource. + + Identifier system: A managed collection of names. This document + refers to identifier systems outside the context of URNs as + "non-URN identifier systems". + + URN namespace: An identifier system that is associated with a URN + NID. + + NID: The identifier associated with a URN namespace. + + NSS: The URN-namespace-specific part of a URN. + + Assigned-name: The combination of the "urn:" scheme, the NID, and + the namespace specific string (NSS). An "assigned-name" is + consequently a substring of a URN (as defined above) if that URN + contains any additional components (see Section 2). + + The term "name" is deliberately not defined here and should be (and, + in practice, is) used only very informally. RFC 3986 uses the term + as a category of URI distinguished from "locator" (Section 1.1.3) but + also uses it in other contexts. If those uses are treated as + definitional, they would conflict with, e.g., the idea of URN + namespace names (i.e., NIDs) and with terms associated with non-URN + identifier systems. + + This document uses the terms "resource", "identifier", "identify", + "dereference", "representation", and "metadata" roughly as defined in + the URI specification [RFC3986]. + + + + + +Saint-Andre & Klensin Standards Track [Page 6] + +RFC 8141 URNs April 2017 + + + This document uses the terms "resolution" and "resolver" in roughly + the sense in which they were used in the original discussion of + architectural principles for URNs [RFC2276], i.e., "resolution" is + the act of supplying services related to the identified resource, + such as translating the persistent URN into one or more current + locators for the resource, delivering metadata about the resource in + an appropriate format, or even delivering a representation of the + resource (e.g., a document) without requiring further intermediaries. + At the time of this writing, resolution services are described in + [RFC2483]. + + On the distinction between representations and metadata, see + Section 1.2.2 of [RFC3986]. + + Several other terms related to "normalization" operations that are + not part of the Unicode Standard [UNICODE] are also used here as they + are in RFC 3986. + + 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]. + +1.2. Design Trade-offs + + To a degree much greater than when URNs were first considered and + their uses outlined (see [RFC1737]), issues of persistent identifiers + on the Internet involve fundamental design trade-offs that are much + broader than URNs or the URN approach and even touch on open research + questions within the information sciences community. Ideal and + comprehensive specifications about what should be done or required + across the entire universe of URNs would require general agreement + about, and solutions to, a wide range of such issues. Although some + of those issues were introduced by the Internet or computer-age + approaches to character encodings and data abstraction, others + predate the Internet and computer systems by centuries; there is + unlikely to be agreement about comprehensive solutions in the near + future. + + Although this specification consequently contains some requirements + and flexibility that would not be present in a more perfect world, + this has been necessary in order to produce a consensus specification + that provides a modernized definition of URNs (the unattractive + alternative would have been to not modernize the definition in spite + of widespread deployment). + + The following sub-sections describe two of the relevant issues in + greater detail. + + + +Saint-Andre & Klensin Standards Track [Page 7] + +RFC 8141 URNs April 2017 + + +1.2.1. Resolution + + One issue that is specific to URNs (as opposed to naming systems in + general) is the fairly difficult topic of "resolution", discussed in + Sections 1.1, 2.3.1, 6.4.6, and elsewhere below. + + With traditional Uniform Resource Locators (URLs), i.e., with most + URIs that are locators, resolution is relatively straightforward + because it is used to determine an access mechanism that in turn is + used to dereference the locator by (typically) retrieving a + representation of the associated resource, such as a document (see + Section 1.2.2 of [RFC3986]). + + By contrast, resolution for URNs is more flexible and varied. + + One important case involves the mapping of a URN to one or more + locators. In this case, the end result is still a matter of + dereferencing the mapped locator(s) to one or more representations. + The primary difference here is persistence: even if a mapped locator + has changed (e.g., a DNS domain name has changed hands and a URL has + not been modified to point to a new location or, in a more extreme + and hypothetical case, the DNS is replaced entirely), a URN user will + be able to obtain the correct representation (e.g., a document) as + long as the resolver has kept its URN-to-locator mappings up to date. + Consequently, the relevant relationships can be defined quite + precisely for URNs that resolve to locators that in turn are + dereferenced to a representation. + + However, this specification permits several other cases of URN + resolution as well as URNs for resources that do not involve + information retrieval systems. This is true either individually for + particular URNs or (as defined below) collectively for entire URN + namespaces. + + Consider a namespace of URNs that resolve to locators that in turn + are dereferenced only to metadata about resources because the + underlying systems contain no representations of those resources; an + example might be a URN namespace for International Standard Name + Identifiers (ISNIs) as that identifier system is defined in the + relevant standard [ISO.27729.2012], wherein by default a URN would be + resolved only to a metadata record describing the public identity + identified by the ISNI. + + Consider also URNs that resolve to representations only if the + requesting entity is authorized to obtain the representation, whereas + other entities can obtain only metadata about the resource; an + example might be documents held within the legal depository + collection of a national library. + + + +Saint-Andre & Klensin Standards Track [Page 8] + +RFC 8141 URNs April 2017 + + + Finally, some URNs might not be intended to resolve to locators at + all; examples might include URNs identifying XML namespace names + (e.g., the "dgiwg" URN namespace specified by [RFC6288]), URNs + identifying application features that can be supported within a + communications protocol (e.g., the "alert" URN namespace specified by + [RFC7462]), and URNs identifying enumerated types such as values in a + registry (e.g., a URN namespace could be used to individually + identify the values in all IANA registries, as provisionally proposed + in [IANA-URN]). + + Various types of URNs and multiple resolution services that may be + available for them leave the concept of "resolution" more complicated + but also much richer for URNs than the straightforward case of + resolution to a locator that is dereferenced to a representation. + +1.2.2. Character Sets and Encodings + + A similar set of considerations apply to character sets and + encodings. URNs, especially URNs that will be used as user-facing + identifiers, should be convenient to use in local languages and + writing systems, easily specified with a wide range of keyboards and + local conventions, and unambiguous. There are trade-offs among those + goals, and it is impossible at present to see how a simple and + readily understandable set of rules could be developed that would be + optimal, or even reasonable, for all URNs. The discussion in + Section 2.2 defines an overall framework that should make generalized + parsing and processing possible but also makes recommendations about + rules for individual URN namespaces. + +2. URN Syntax + + As discussed above, the syntax for URNs in this specification allows + significantly more functionality than was the case in the earlier + specifications, most recently [RFC2141]. It is also harmonized with + the general URI syntax [RFC3986] (which, it must be noted, was + completed after the earlier URN specifications). + + However, this specification does not extend the URN syntax to allow + direct use of characters outside the ASCII range [RFC20]. That + restriction implies that any such characters need to be percent- + encoded as described in Section 2.1 of the URI specification + [RFC3986]. + + The basic syntax for a URN is defined using the Augmented Backus-Naur + Form (ABNF) as specified in [RFC5234]. Rules not defined here + (specifically: alphanum, fragment, and pchar) are defined as part of + the URI syntax [RFC3986] and used here to point out the syntactic + relationship with the terms used there. The definitions of some of + + + +Saint-Andre & Klensin Standards Track [Page 9] + +RFC 8141 URNs April 2017 + + + the terms used below are not comprehensive; additional restrictions + are imposed by the prose that can be found in sections of this + document that are specific to those terms (especially r-component in + Section 2.3.1 and q-component in Section 2.3.2). + + namestring = assigned-name + [ rq-components ] + [ "#" f-component ] + assigned-name = "urn" ":" NID ":" NSS + NID = (alphanum) 0*30(ldh) (alphanum) + ldh = alphanum / "-" + NSS = pchar *(pchar / "/") + rq-components = [ "?+" r-component ] + [ "?=" q-component ] + r-component = pchar *( pchar / "/" / "?" ) + q-component = pchar *( pchar / "/" / "?" ) + f-component = fragment + + The question mark character "?" can be used without percent-encoding + inside r-components, q-components, and f-components. Other than + inside those components, a "?" that is not immediately followed by + "=" or "+" is not defined for URNs and SHOULD be treated as a syntax + error by URN-specific parsers and other processors. + + The following sections provide additional information about the + syntactic elements of URNs. + +2.1. Namespace Identifier (NID) + + NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent). + + Characters outside the ASCII range [RFC20] are not permitted in NIDs, + and no encoding mechanism for such characters is supported. + + Sections 5.1 and 5.2 impose additional constraints on the strings + that can be used as NIDs, i.e., the syntax shown above is not + comprehensive. + +2.2. Namespace Specific String (NSS) + + The NSS is a string, unique within a URN namespace, that is assigned + and managed in a consistent way and that conforms to the definition + of the relevant URN namespace. The combination of the NID (unique + across the entire "urn" scheme) and the NSS (unique within the URN + namespace) ensures that the resulting URN is globally unique. + + + + + + +Saint-Andre & Klensin Standards Track [Page 10] + +RFC 8141 URNs April 2017 + + + The NSS as specified in this document allows several characters not + permitted by earlier specifications (see Appendix B). In particular, + the "/" character, which is now allowed, effectively makes it + possible to encapsulate hierarchical names from non-URN identifier + systems. For instance, consider the hypothetical example of a + hierarchical identifier system in which the names take the form of a + sequence of numbers separated by the "/" character, such as + "1/406/47452/2". If the authority for such names were to use URNs, + it would be natural to place the existing name in the NSS, resulting + in URNs such as "urn:example:1/406/47452/2". + + Those changes to the syntax for the NSS do not modify the encoding + rules for URN namespaces that were defined in accordance with + [RFC2141]. If any such URN namespace whose names are used outside of + the URN context (i.e., in a non-URN identifier system) also allows + the use of "/", "~", or "&" in the native form within that identifier + system, then the encoding rules for that URN namespace are not + changed by this specification. + + Depending on the rules governing a non-URN identifier system and its + associated URN namespace, names that are valid in that identifier + system might contain characters that are not allowed by the "pchar" + production referenced above (e.g., characters outside the ASCII range + or, consistent with the restrictions in RFC 3986, the characters "/", + "?", "#", "[", and "]"). While such a name might be valid within the + non-URN identifier system, it is not a valid URN until it has been + translated into an NSS that conforms to the rules of that particular + URN namespace. In the case of URNs that are formed from names that + exist separately in a non-URN identifier system, translation of a + name from its "native" format to a URN format is accomplished by + using the canonicalization and encoding methods defined for URNs in + general or specific rules for that URN namespace. Software that is + not aware of namespace-specific canonicalization and encoding rules + MUST NOT construct URNs from the name in the non-URN identifier + system. + + In particular, with regard to characters outside the ASCII range, + URNs that appear in protocols or that are passed between systems MUST + use only Unicode characters encoded in UTF-8 and further encoded as + required by RFC 3986. To the extent feasible and consistent with the + requirements of names defined and standardized elsewhere, as well as + the principles discussed in Section 1.2, the characters used to + represent names SHOULD be restricted to either ASCII letters and + digits or to the characters and syntax of some widely used models + such as those of Internationalizing Domain Names in Applications + (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of + Internationalized Strings (PRECIS) [RFC7613], or the Unicode + Identifier and Pattern Syntax specification [UAX31]. + + + +Saint-Andre & Klensin Standards Track [Page 11] + +RFC 8141 URNs April 2017 + + + In order to make URNs as stable and persistent as possible when + protocols evolve and the environment around them changes, URN + namespaces SHOULD NOT allow characters outside the ASCII range + [RFC20] unless the nature of the particular URN namespace makes such + characters necessary. + +2.3. Optional Components + + This specification includes three optional components in the URN + syntax. They are known as r-component, q-component, and f-component + and are described in more detail below. Because this specification + focuses almost exclusively on URN syntax, it does not define detailed + semantics of these components for URNs in general. However, each of + these components has a distinct role that is independent of any given + URN and its URN namespace. It is intended that clients will be able + to handle these components uniformly for all URNs. These components + MAY be used with URNs from existing URN namespaces, whether or not a + URN namespace explicitly supports them. However, consistent with the + approach taken in RFC 3986, the behavior of a URN that contains + components that are undefined or meaningless for a particular URN + namespace or resource is not defined. The following sections + describe these optional components and their interpretation in + greater detail. + +2.3.1. r-component + + The r-component is intended for passing parameters to URN resolution + services (taken broadly, see Section 1.2) and interpreted by those + services. (By contrast, passing parameters to the resources + identified by a URN, or to applications that manage such resources, + is handled by q-components as described in the next section.) + + The URN r-component has no syntactic counterpart in any other known + URI scheme. + + The sequence "?+" introduces the r-component. The r-component ends + with a "?=" sequence (which begins a q-component) or a "#" character + (number sign, which begins an f-component). If neither of those + appear, the r-component continues to the end of the URN. Note that + characters outside the ASCII range [RFC20] MUST be percent-encoded + using the method defined in Section 2.1 of the generic URI + specification [RFC3986]. + + As described in Section 3, the r-component SHALL NOT be taken into + account when determining URN-equivalence. However, the r-component + SHALL be supplied along with the URN when presenting a request to a + URN resolution service. + + + + +Saint-Andre & Klensin Standards Track [Page 12] + +RFC 8141 URNs April 2017 + + + This document defines only the syntax of the r-component and reserves + it for future use. The exact semantics of the r-component and its + use in URN resolution protocols are a matter for potential + standardization in separate specifications, presumably including + specifications that define conventions and a registry for resolution + service identifiers. + + Consider the hypothetical example of passing parameters to a + resolution service (say, an ISO alpha-2 country code [ISO.3166-1] in + order to select the preferred country in which to search for a + physical copy of a book). This could perhaps be accomplished by + specifying the country code in the r-component, resulting in URNs + such as: + + urn:example:foo-bar-baz-qux?+CCResolve:cc=uk + + While the above should serve as a general explanation and + illustration of the intent for r-components, there are many open + issues with them, including their relationship to resolution + mechanisms associated with the particular URN namespace at + registration time. Thus, r-components SHOULD NOT be used for URNs + before their semantics have been standardized. + +2.3.2. q-component + + The q-component is intended for passing parameters to either the + named resource or a system that can supply the requested service, for + interpretation by that resource or system. (By contrast, passing + parameters to URN resolution services is handled by r-components as + described in the previous section.) + + The URN q-component has the same syntax as the URI query component + but is introduced by "?=", not "?" alone. For a URN that may be + resolved to a URI that is a locator, the semantics of the q-component + are identical to those for the query component of that URI. Thus, + URN resolvers returning a URI that is a locator for a URN with a + q-component do this by copying the q-component from the URN to the + query component of the URI. An example of the copying operation + appears below. + + This specification does not specify a required behavior in the case + of URN resolution to a URI that is a locator when the original URN + has a q-component and the URI has a query string. Different + circumstances may require different approaches. Resolvers SHOULD + document their strategy in such cases. + + + + + + +Saint-Andre & Klensin Standards Track [Page 13] + +RFC 8141 URNs April 2017 + + + If the URN does not resolve to a URI that is a locator, the + interpretation of the q-component is undefined by this specification. + For URNs that may be resolved to a URI that is a locator, the + semantics of the q-component are identical to those for queries to + the resource located via that URI. + + For the sake of consistency with RFC 3986, the general syntax and the + semantics of q-components are not defined by, or dependent on, the + URN namespace of the URN. In parallel with RFC 3986, specifics of + syntax and semantics, e.g., which keywords or terms are meaningful, + of course may depend on a particular URN namespace or even a + particular resource. + + The sequence "?=" introduces the q-component. The q-component ends + with a "#" character (number sign, which begins an f-component). If + that character does not appear, the q-component continues to the end + of the URN. The characters slash ("/") and question mark ("?") may + represent data within the q-component. Note that characters outside + the ASCII range [RFC20] MUST be percent-encoded using the method + defined in Section 2.1 of the generic URI specification [RFC3986]. + + As described in Section 3, the q-component SHALL NOT be taken into + account when determining URN-equivalence. + + URN namespaces and associated information placement in syntax SHOULD + be designed to avoid any need for a resolution service to consider + the q-component. Namespace-specific and more generic resolution + systems MUST NOT require that q-component information be passed to + them for processing. + + Consider the hypothetical example of passing parameters to an + application that returns weather reports from different regions or + for different time periods. This could perhaps be accomplished by + specifying latitude and longitude coordinates and datetimes in the + URN's q-component, resulting in URNs such as the following. + + urn:example:weather?=op=map&lat=39.56 + &lon=-104.85&datetime=1969-07-21T02:56:15Z + + If this example resolved to an HTTP URI, the result might look like: + + https://weatherapp.example?op=map&lat=39.56 + &lon=-104.85&datetime=1969-07-21T02:56:15Z + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 14] + +RFC 8141 URNs April 2017 + + +2.3.3. f-component + + The f-component is intended to be interpreted by the client as a + specification for a location within, or region of, the named + resource. It distinguishes the constituent parts of a resource named + by a URN. For a URN that resolves to one or more locators that can + be dereferenced to a representation, or where the URN resolver + directly returns a representation of the resource, the semantics of + an f-component are defined by the media type of the representation. + + The URN f-component has the same syntax as the URI fragment + component. If a URN containing an f-component resolves to a single + URI that is a locator associated with the named resource, the + f-component from the URN can be applied (usually by the client) as + the fragment of that URI. If the URN does not resolve to a URI that + is a locator, the interpretation of the f-component is undefined by + this specification. Thus, for URNs that may be resolved to a URI + that is a locator, the semantics of f-components are identical to + those of fragments for that resource. + + For the sake of consistency with RFC 3986, neither the general syntax + nor the semantics of f-components are defined by, or dependent on, + the URN namespace of the URN. In parallel with RFC 3986, specifics + of syntax and semantics, e.g., which keywords or terms are + meaningful, of course may depend on a particular URN namespace or + even a particular resource. + + The f-component is introduced by the number sign ("#") character and + terminated by the end of the URI. Any characters outside the ASCII + range [RFC20] that appear in the f-component MUST be percent-encoded + using the method defined in Section 2.1 of the generic URI + specification [RFC3986]. + + As described in Section 3, the f-component SHALL NOT be taken into + account when determining URN-equivalence. + + Clients SHOULD NOT pass f-components to resolution services unless + those services also perform object retrieval and interpretation + functions. + + Consider the hypothetical example of obtaining resources that are + part of a larger entity (say, the chapters of a book). Each part + could be specified in the f-component, resulting in URNs such as: + + urn:example:foo-bar-baz-qux#somepart + + + + + + +Saint-Andre & Klensin Standards Track [Page 15] + +RFC 8141 URNs April 2017 + + +3. URN-Equivalence + +3.1. Procedure + + For various purposes such as caching, it is often desirable to + determine if two URNs are "the same". This is done most generally + (i.e., independent of the scheme) by testing for equivalence (see + Section 6.1 of [RFC3986]). + + The generic URI specification [RFC3986] is very flexible about + equality comparisons, putting the focus on allowing false negatives + and avoiding false positives. If comparisons are made in a scheme- + independent way, i.e., as URI comparisons only, many URNs that this + specification considers equal would be rejected. The discussion + below applies when the URIs involved are known to be URNs and thus + uses the terms "URN-equivalent" and "URN-equivalence" to refer to + equivalence as specified in this document. + + Two URNs are URN-equivalent if their assigned-name portions are + octet-by-octet equal after applying case normalization (as specified + in Section 6.2.2.1 of [RFC3986]) to the following constructs: + + 1. the URI scheme "urn", by conversion to lower case + + 2. the NID, by conversion to lower case + + 3. any percent-encoded characters in the NSS (that is, all character + triplets that match the <pct-encoding> production found in + Section 2.1 of the base URI specification [RFC3986]), by + conversion to upper case for the digits A-F. + + Percent-encoded characters MUST NOT be decoded, i.e., percent- + encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) + MUST NOT be applied as part of the comparison process. + + If an r-component, q-component, or f-component (or any combination + thereof) is included in a URN, it MUST be ignored for purposes of + determining URN-equivalence. + + URN namespace definitions MAY include additional rules for + URN-equivalence, such as case insensitivity of the NSS (or parts + thereof). Such rules MUST always have the effect of eliminating some + of the false negatives obtained by the procedure above and MUST NOT + result in treating two URNs as not "the same" if the procedure here + says they are URN-equivalent. For related considerations with regard + to NID registration, see below. + + + + + +Saint-Andre & Klensin Standards Track [Page 16] + +RFC 8141 URNs April 2017 + + +3.2. Examples + + This section shows a variety of URNs (using the "example" NID defined + in [RFC6963]) that highlight the URN-equivalence rules. + + First, because the scheme and NID are case insensitive, the following + three URNs are URN-equivalent to each other: + + o urn:example:a123,z456 + + o URN:example:a123,z456 + + o urn:EXAMPLE:a123,z456 + + Second, because the r-component, q-component, and f-component are not + taken into account for purposes of testing URN-equivalence, the + following three URNs are URN-equivalent to the first three examples + above: + + o urn:example:a123,z456?+abc + + o urn:example:a123,z456?=xyz + + o urn:example:a123,z456#789 + + Third, because the "/" character (and anything that follows it) in + the NSS is taken into account for purposes of URN-equivalence, the + following URNs are not URN-equivalent to each other or to the six + preceding URNs: + + o urn:example:a123,z456/foo + + o urn:example:a123,z456/bar + + o urn:example:a123,z456/baz + + Fourth, because of percent-encoding, the following URNs are + URN-equivalent only to each other and not to any of those above (note + that, although %2C is the percent-encoded transformation of "," from + the previous examples, such sequences are not decoded for purposes of + testing URN-equivalence): + + o urn:example:a123%2Cz456 + + o URN:EXAMPLE:a123%2cz456 + + + + + + +Saint-Andre & Klensin Standards Track [Page 17] + +RFC 8141 URNs April 2017 + + + Fifth, because characters in the NSS other than percent-encoded + sequences are treated in a case-sensitive manner (unless otherwise + specified for the URN namespace in question), the following URNs are + not URN-equivalent to the first three URNs: + + o urn:example:A123,z456 + + o urn:example:a123,Z456 + + Sixth, on casual visual inspection of a URN presented in a human- + oriented interface, the following URN might appear the same as the + first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be + confused with U+0061 LATIN SMALL LETTER A), but it is not + URN-equivalent to the first three URNs: + + o urn:example:%D0%B0123,z456 + +4. URI Conformance + +4.1. Use in URI Protocol Slots + + Because a URN is, syntactically, a URI under the "urn" scheme, in + theory a URN can be placed in any protocol slot that allows for a URI + (to name just a few, the "href" and "src" attributes in HTML, the + base element in HTML, the "xml:base" attribute in XML [XML-BASE], and + the "xmlns" attribute in XML for XML namespace names [XML-NAMES]). + + However, this does not imply that, semantically, it always makes + sense in practice to place a URN in a given URI protocol slot; in + particular, because a URN might not specify the location of a + resource or even point indirectly to one, it might not be appropriate + to place a URN in a URI protocol slot that points to a resource + (e.g., the aforementioned "href" and "src" attributes). + + Ultimately, guidelines regarding when it is appropriate to use URIs + under the "urn" scheme (or any other scheme) are the responsibility + of specifications for individual URI protocol slots (e.g., the + specification for the "xml:base" attribute in XML might recommend + that it is inappropriate to use URNs in that protocol slot). This + specification cannot possibly anticipate all of the relevant cases, + and it is not the place of this specification to require or restrict + usage for individual protocol slots. + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 18] + +RFC 8141 URNs April 2017 + + +4.2. Parsing + + In part because of the separation of URN semantics from more general + URI syntax, generic URI processors need to pay special attention to + the parsing and analysis rules of RFC 3986 and, in particular, must + treat the URI as opaque unless the scheme and its requirements are + recognized. In the latter case, such processors may be in a position + to invoke scheme-appropriate processing, e.g., by a URN resolver. A + URN resolver can either be an external resolver that the URI resolver + knows of or be functionality built into the URI resolver. Note that + this requirement might impose constraints on the contexts in which + URNs are appropriately used; see Section 4.1. + +4.3. URNs and Relative References + + Section 5.2 of [RFC3986] describes an algorithm for converting a URI + reference that might be relative to a given base URI into "parsed + components" of the target of that reference, which can then be + recomposed per RFC 3986, Section 5.3 into a target URI. This + algorithm is problematic for URNs because their syntax does not + support the necessary path components. However, if the algorithm is + applied independent of a particular scheme, it should work + predictably for URNs as well, with the following understandings + (syntax production terminology taken from RFC 3986): + + 1. A system that encounters a <URI-reference> that obeys the syntax + for <relative-ref>, whether it explicitly has the scheme "urn" or + not, will convert it into a target URI as specified in RFC 3986. + + 2. Because of the persistence and stability expectations of URNs, + authors of documents, etc., that utilize URNs should generally + avoid the use of the "urn" scheme in any <URI-reference> that is + not strictly a <URI> as specified in RFC 3986, specifically + including those that would require processing of <relative-ref>. + +4.4. Transport and Display + + When URNs are transported and exchanged, they MUST be represented in + the format defined herein. Further, URN-aware applications are + strongly encouraged to offer the option of displaying URNs in this + canonical form to allow for direct transcription (for example by + copy-and-paste techniques). Such applications might support the + display of URNs in a more human-friendly form and might use a + character set that includes characters that are not permitted in URN + syntax as defined in this specification (e.g., when displaying URNs + to humans, such applications might replace percent-encoded strings + with characters from an extended character repertoire such as Unicode + [UNICODE]). + + + +Saint-Andre & Klensin Standards Track [Page 19] + +RFC 8141 URNs April 2017 + + + To minimize user confusion, any application displaying URIs SHOULD + display the complete URI (including, for URNs, the "urn" scheme and + any components) to ensure that there is no confusion between URN NIDs + and URI scheme identifiers. For example, a URI beginning with + "urn:xmpp:" [RFC4854] is very different from a URI beginning with + "xmpp:" [RFC5122]. Similarly, a potential Digital Object Identifier + (DOI) URI scheme [DOI-URI] is different from, and possibly completely + unrelated to, a possible DOI URN namespace. + +4.5. URI Design and Ownership + + As mentioned, the assignment of URNs within a URN namespace is a + managed process, as is the assignment of URN namespaces themselves. + Although design of the URNs to be assigned within a given URN + namespace is ceded by this specification to the URN namespace + manager, doing so in a managed way avoids the problems inherent in + unmanaged generation of URIs as described in the recommendations + regarding URI design and ownership [RFC7320]. + +5. URN Namespaces + + A URN namespace is a collection of names that obey three constraints: + each name is (1) unique, (2) assigned in a consistent way, and (3) + assigned according to a common definition. + + 1. The "uniqueness" constraint means that a name within the URN + namespace is never assigned to more than one resource and never + reassigned to a different resource (for the kind of "resource" + identified by URNs assigned within the URN namespace). This + holds true even if the name itself is deprecated or becomes + obsolete. + + 2. The "consistent assignment" constraint means that a name within + the URN namespace is assigned by an organization or created in + accordance with a process or algorithm that is always followed. + + 3. The "common definition" constraint means that there are clear + definitions for the syntax of names within the URN namespace and + for the process of assigning or creating them. + + A URN namespace is identified by a particular NID in order to ensure + the global uniqueness of URNs and, optionally, to provide a cue + regarding the structure of URNs assigned within a URN namespace. + + With regard to global uniqueness, using different NIDs for different + collections of names ensures that no two URNs will be the same for + different resources, because each collection is required to uniquely + assign each name. However, a single resource MAY have more than one + + + +Saint-Andre & Klensin Standards Track [Page 20] + +RFC 8141 URNs April 2017 + + + URN assigned to it, either in the same URN namespace (if the URN + namespace permits it) or in different URN namespaces, and for either + similar purposes or different purposes. (For example, if a publisher + assigns an ISBN [RFC3187] to an electronic publication and that + publication is later incorporated into a digital long-term archive + operated by a national library, the library might assign the + publication a national bibliography number (NBN) [RFC3188], resulting + in two URNs referring to the same book.) Subject to other + constraints, such as those imposed by the URI syntax [RFC3986], the + rules of the URN scheme are intended to allow preserving the normal + and natural form of names specified in non-URN identifier systems + when they are treated as URNs. + + With regard to the structure of names assigned within a URN + namespace, the development of a naming structure (and thereby a + collection of names) depends on the requirements of the community + defining the names, how the names will be assigned and used, etc. + These issues are beyond the scope of URN syntax and the general rules + for URN namespaces, because they are specific to the community + defining a non-URN identifier system or a particular URN namespace + (e.g., the bibliographic and publishing communities in the case of + the "ISBN" URN namespace [RFC3187] and the "ISSN" URN namespace + [RFC3044] or the developers of extensions to the Extensible Messaging + and Presence Protocol [RFC6120] in the case of the "XMPP" URN + namespace [RFC4854]). + + Because the colon character (":") is used to separate "urn" from the + NID and the NID from the NSS, it's tempting to think of the entire + URN as being structured by colon characters and to assume that colons + create a structure or hierarchy within the NSS portion of the URN. + Such structure could be specified by a particular NID specification, + but there is no implicit structure. In a URN such as + + urn:example:apple:pear:plum:cherry + + the NSS string is "apple:pear:plum:cherry" as a whole, and there is + no specific meaning to the colon characters within that NSS string + unless such meaning is described in the specification of the + "example" namespace. + + URN namespaces inherit certain rights and responsibilities by the + nature of URNs, in particular: + + 1. They uphold the general principles of a well-managed URN + namespace by providing persistent identification of resources and + unique assignment of names in accordance with a common + definition. + + + + +Saint-Andre & Klensin Standards Track [Page 21] + +RFC 8141 URNs April 2017 + + + 2. Optionally, they can be registered in global registration + services such as those described in [RFC2483]. + + There are two types of URN namespaces: formal and informal. These + are distinguished by the expected level of service, the information + needed to define the URN namespace, and the procedures for + registration. Because the majority of the URN namespaces registered + so far have been formal, this document concentrates on formal URN + namespaces. + +5.1. Formal URN Namespaces + + A formal URN namespace provides benefit to some subset of users on + the Internet. In particular, it would not make sense for a formal + URN namespace to be used only by a community or network that is not + connected to the Internet. For example, it would be inappropriate + for a URN namespace to effectively force someone to use a proprietary + network or service not open to the general Internet user. The intent + is that, while the community of those who might actively use the URNs + assigned within that URN namespace might be small, the potential use + of names within that URN namespace is open to any user on the + Internet. Formal URN namespaces might be appropriate even when some + aspects are not fully open. For example, a URN namespace might make + use of a fee-based, privately managed, or proprietary registry for + assignment of URNs in the URN namespace. However, it might still + benefit some Internet users if the associated services have openly + published names. + + An organization that will assign URNs within a formal URN namespace + SHOULD meet the following criteria: + + 1. Organizational stability and the ability to maintain the URN + namespace for a long time; absent such evidence, it ought to be + clear how the URN namespace can remain viable if the organization + can no longer maintain the URN namespace. + + 2. Competency in URN assignment. This will improve the likelihood + of persistence (e.g., to minimize the likelihood of conflicts). + + 3. Commitment to not reassigning existing URNs and to allowing old + URNs to continue to be valid (e.g., if the assignee of a URN is + no longer a member or customer of the assigning organization, if + various information about the assignee or named entity happens to + change, or even if the assignee or the named entity itself is no + longer in existence; in all these cases, the URN is still valid). + + + + + + +Saint-Andre & Klensin Standards Track [Page 22] + +RFC 8141 URNs April 2017 + + + A formal URN namespace establishes a particular NID, subject to the + following constraints (above and beyond the syntax rules already + specified): + + 1. It MUST NOT be an already-registered NID. + + 2. It MUST NOT start with "urn-" (which is reserved for informal URN + namespaces). + + 3. It MUST be more than two characters long, and it MUST NOT start + with ALPHA ALPHA "-", i.e., any string consisting of two letters + followed by one hyphen; such strings are reserved for potential + use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for + eventual national registrations of URN namespaces (however, the + definition and scoping of rules for allocation of responsibility + for such country-code-based URN namespaces are beyond the scope + of this document). As a consequence, it MUST NOT start with the + string "xn--" or any other string consisting of two letters + followed by two hyphens; such strings are reserved for potential + representation of DNS A-labels and similar strings in the future + [RFC5890]. + + 4. It MUST NOT start with the string "X-" so that it will not be + confused with or conflict with any experimental URN namespace + previously permitted by [RFC3406]. + + Applicants and reviewers considering new NIDs should also be aware + that they may have semantic implications and hence be a source of + conflict. Particular attention should be paid to strings that might + be construed as identifiers for, or registered under the authority + of, countries (including ISO 3166-1 alpha-3 codes) and to strings + that might imply association with existing URI schemes, non-URN + identifier systems, or trademarks. However, in line with traditional + policies, disputes about "ownership" of particular strings are + disagreements among the parties involved; neither IANA nor the IETF + will become involved in such disputes except in response to orders + from a court of competent jurisdiction. + +5.2. Informal URN Namespaces + + Informal URN namespaces are full-fledged URN namespaces, with all the + associated rights and responsibilities. Informal URN namespaces + differ from formal URN namespaces in the process for assigning the + NID: for an informal URN namespace, the registrant does not designate + the NID; instead, IANA assigns the NID consisting of the string + "urn-" followed by one or more digits (e.g., "urn-7") where the + + + + + +Saint-Andre & Klensin Standards Track [Page 23] + +RFC 8141 URNs April 2017 + + + digits consist of the next available number in the sequence of + positive integers assigned to informal URN namespaces. Thus, the + syntax of an informal URN namespace identifier is: + + InformalNamespaceName = "urn-" Number + Number = DigitNonZero 0*Digit + DigitNonZero = "1"/ "2" / "3" / "4"/ "5" + / "6" / "7" / "8" / "9" + Digit = "0" / DigitNonZero + + The only restrictions on <Number> are that it (1) consist strictly of + ASCII digits, (2) not have leading zeros, and (3) not cause the NID + to exceed the length limitations defined for the URN syntax (see + Section 2). + +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. + + + + + + + +Saint-Andre & Klensin Standards Track [Page 24] + +RFC 8141 URNs April 2017 + + +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 urn@ietf.org 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 + + + +Saint-Andre & Klensin Standards Track [Page 25] + +RFC 8141 URNs April 2017 + + + 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. + + + + + +Saint-Andre & Klensin Standards Track [Page 26] + +RFC 8141 URNs April 2017 + + + 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. + + + + + + +Saint-Andre & Klensin Standards Track [Page 27] + +RFC 8141 URNs April 2017 + + +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. + + + + + +Saint-Andre & Klensin Standards Track [Page 28] + +RFC 8141 URNs April 2017 + + +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: + + o 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]). + + o Leakage of private information when names are communicated on the + public Internet. + + o The potential for directory harvesting. + + o 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. + + + + + + +Saint-Andre & Klensin Standards Track [Page 29] + +RFC 8141 URNs April 2017 + + +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. + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 30] + +RFC 8141 URNs April 2017 + + +7. IANA Considerations + +7.1. URI Scheme + + This section updates the registration of the "urn" URI scheme in the + Permanent URI Registry [URI-Registry]. + + URI Scheme Name: urn + + Status: permanent + + URI Scheme Syntax: See Section 2 of RFC 8141. + + URI Scheme Semantics: The "urn" scheme identifies Uniform Resource + Names, which are persistent, location-independent resource + identifiers. + + Encoding Considerations: See Section 2 of RFC 8141. + + Applications/Protocols That Use This URI Scheme Name: Uniform + Resource Names are used in a wide variety of applications, + including bibliographic reference systems and as names for + Extensible Markup Language (XML) namespaces. + + Interoperability Considerations: See Section 4 of RFC 8141. + + Security Considerations: See Sections 6.4.4 and 8 of RFC 8141. + + Contact: URNBIS working group [mailto:urn@ietf.org] + + Author/Change Controller: This scheme is registered under the IETF + tree. As such, the IETF maintains change control. + + References: None. + +7.2. Registration of URN Namespaces + + This document outlines the processes for registering URN namespaces + and has implications for the IANA in terms of registries to be + maintained (see especially Section 6). In all cases, the IANA ought + to assign the appropriate NID (formal or informal) once the + procedures outlined in Section 6 have been completed. + +7.3. Discussion List for New and Updated NID Registrations + + As discussed elsewhere in this document, the discussion list + specified in RFC 3406 (urn-nid@apps.ietf.org) is discontinued and + replaced by the discussion list urn@ietf.org. + + + +Saint-Andre & Klensin Standards Track [Page 31] + +RFC 8141 URNs April 2017 + + +8. Security and Privacy Considerations + + The definition of a URN namespace needs to account for potential + security and privacy issues related to assignment, use, and + resolution of names within the URN namespace (e.g., some URN + resolvers might assign special meaning to certain characters in the + NSS); see Section 6.4.4 for further discussion. + + In most cases, URN namespaces provide a way to declare public + information. Normally, these declarations will have a relatively low + security profile; however, there is always the danger of "spoofing" + and providing misinformation. Information in these declarations + ought to be taken as advisory. + +9. References + +9.1. Normative References + + [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, + RFC 20, DOI 10.17487/RFC0020, October 1969, + <http://www.rfc-editor.org/info/rfc20>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <http://www.rfc-editor.org/info/rfc5234>. + +9.2. Informative References + + [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The + "doi" URI Scheme for the Digital Object Identifier (DOI)", + Work in Progress, draft-paskin-doi-uri-04, June 2003. + + + + +Saint-Andre & Klensin Standards Track [Page 32] + +RFC 8141 URNs April 2017 + + + [IANA-URN] Saint-Andre, P. and M. Cotton, "A Uniform Resource Name + (URN) Namespace for IANA Registries", Work in Progress, + draft-saintandre-iana-urn-01, February 2013. + + [ISO.27729.2012] + ISO, "Information and documentation - International + standard name identifier (ISNI)", ISO 27729:2012, + Technical Committee ISO/TC 46, Information and + documentation, Subcommittee SC 9, Identification and + description, March 2012. + + [ISO.3166-1] + ISO, "Codes for the representation of names of countries + and their subdivisions -- Part 1: Country codes", + ISO 3166-1:2013, November 2013. + + [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737, + December 1994, <http://www.rfc-editor.org/info/rfc1737>. + + [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, + December 1994, <http://www.rfc-editor.org/info/rfc1738>. + + [RFC1808] Fielding, R., "Relative Uniform Resource Locators", + RFC 1808, DOI 10.17487/RFC1808, June 1995, + <http://www.rfc-editor.org/info/rfc1808>. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, + May 1997, <http://www.rfc-editor.org/info/rfc2141>. + + [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource + Name Resolution", RFC 2276, DOI 10.17487/RFC2276, January + 1998, <http://www.rfc-editor.org/info/rfc2276>. + + [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services + Necessary for URN Resolution", RFC 2483, + DOI 10.17487/RFC2483, January 1999, + <http://www.rfc-editor.org/info/rfc2483>. + + [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, + DOI 10.17487/RFC2648, August 1999, + <http://www.rfc-editor.org/info/rfc2648>. + + [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial + Standard Number) as URN (Uniform Resource Names) within an + ISSN-URN Namespace", RFC 3044, DOI 10.17487/RFC3044, + January 2001, <http://www.rfc-editor.org/info/rfc3044>. + + + +Saint-Andre & Klensin Standards Track [Page 33] + +RFC 8141 URNs April 2017 + + + [RFC3187] Hakala, J. and H. Walravens, "Using International Standard + Book Numbers as Uniform Resource Names", RFC 3187, + DOI 10.17487/RFC3187, October 2001, + <http://www.rfc-editor.org/info/rfc3187>. + + [RFC3188] Hakala, J., "Using National Bibliography Numbers as + Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, + October 2001, <http://www.rfc-editor.org/info/rfc3188>. + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, + "Uniform Resource Names (URN) Namespace Definition + Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, + October 2002, <http://www.rfc-editor.org/info/rfc3406>. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + <http://www.rfc-editor.org/info/rfc3552>. + + [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace + for Extensions to the Extensible Messaging and Presence + Protocol (XMPP)", RFC 4854, DOI 10.17487/RFC4854, April + 2007, <http://www.rfc-editor.org/info/rfc4854>. + + [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers + (IRIs) and Uniform Resource Identifiers (URIs) for the + Extensible Messaging and Presence Protocol (XMPP)", + RFC 5122, DOI 10.17487/RFC5122, February 2008, + <http://www.rfc-editor.org/info/rfc5122>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <http://www.rfc-editor.org/info/rfc5890>. + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, + March 2011, <http://www.rfc-editor.org/info/rfc6120>. + + [RFC6288] Reed, C., "URN Namespace for the Defence Geospatial + Information Working Group (DGIWG)", RFC 6288, + DOI 10.17487/RFC6288, August 2011, + <http://www.rfc-editor.org/info/rfc6288>. + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 34] + +RFC 8141 URNs April 2017 + + + [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, + "Deprecating the "X-" Prefix and Similar Constructs in + Application Protocols", BCP 178, RFC 6648, + DOI 10.17487/RFC6648, June 2012, + <http://www.rfc-editor.org/info/rfc6648>. + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + <http://www.rfc-editor.org/info/rfc6838>. + + [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for + Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May + 2013, <http://www.rfc-editor.org/info/rfc6943>. + + [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace + for Examples", BCP 183, RFC 6963, DOI 10.17487/RFC6963, + May 2013, <http://www.rfc-editor.org/info/rfc6963>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <http://www.rfc-editor.org/info/rfc6973>. + + [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. + Gosden, "A Uniform Resource Name Namespace for the Global + System for Mobile Communications Association (GSMA) and + the International Mobile station Equipment Identity + (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, + <http://www.rfc-editor.org/info/rfc7254>. + + [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", + RFC 7282, DOI 10.17487/RFC7282, June 2014, + <http://www.rfc-editor.org/info/rfc7282>. + + [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, + RFC 7320, DOI 10.17487/RFC7320, July 2014, + <http://www.rfc-editor.org/info/rfc7320>. + + [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and + P. Kyzivat, "URNs for the Alert-Info Header Field of the + Session Initiation Protocol (SIP)", RFC 7462, + DOI 10.17487/RFC7462, March 2015, + <http://www.rfc-editor.org/info/rfc7462>. + + + + + + +Saint-Andre & Klensin Standards Track [Page 35] + +RFC 8141 URNs April 2017 + + + [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, + Enforcement, and Comparison of Internationalized Strings + Representing Usernames and Passwords", RFC 7613, + DOI 10.17487/RFC7613, August 2015, + <http://www.rfc-editor.org/info/rfc7613>. + + [UAX31] The Unicode Consortium, "Unicode Standard Annex #31: + Unicode Identifier and Pattern Syntax", Unicode 9.0.0, + June 2015, <http://unicode.org/reports/tr31/>. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + <http://www.unicode.org/versions/latest/>. + + [URI-Registry] + IANA, "Uniform Resource Identifier (URI) Schemes", + <http://www.iana.org/assignments/uri-schemes>. + + [XML-BASE] Marsh, J. and R. Tobin, "XML Base (Second Edition)", W3C + Recommendation REC-xmlbase-20090128, January 2009, + <http://www.w3.org/TR/2009/REC-xmlbase-20090128>. + + [XML-NAMES] + Thompson, H., Hollander, D., Layman, A., Bray, T., and R. + Tobin, "Namespaces in XML 1.0 (Third Edition)", W3C + Recommendation REC-xml-names-20091208, December 2009, + <http://www.w3.org/TR/2009/REC-xml-names-20091208>. + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 36] + +RFC 8141 URNs April 2017 + + +Appendix A. Registration Template + + Namespace Identifier: Requested of IANA (formal) or assigned by IANA + (informal). + + Version: The version of the registration, starting with 1 and + incrementing by 1 with each new version. + + Date: The date when the registration is requested of IANA, using the + format YYYY-MM-DD. + + Registrant: The person or organization that has registered the NID, + including the name and address of the registering organization, as + well as the name and contact information (email, phone number, or + postal address) of the designated contact person. If the + registrant is a recognized standards development organization, + scientific society, or similar body requesting the fast-track + registration procedure (see Section 6.3), that information should + be clearly indicated in this section of the template. + + Purpose: Described in Section 6.4.1 of this document. + + Syntax: Described in Section 6.4.2 of this document. Unless the + registration explicitly describes the semantics of r-components, + q-components, and f-components in the context of this URN + namespace, those semantics are undefined. + + Assignment: Described in Section 6.4.3 of this document. + + Security and Privacy: Described in Section 6.4.4 of this document. + + Interoperability: Described in Section 6.4.5 of this document. + + Resolution: Described in Section 6.4.6 of this document. + + Documentation: A pointer to an RFC, a specification published by + another standards development organization, or another stable + document that provides further information about this URN + namespace. + + Additional Information: Described in Section 6.4.7 of this document. + + Revision Information: Description of changes from prior version(s). + (Applicable only when earlier registrations have been revised.) + + + + + + + +Saint-Andre & Klensin Standards Track [Page 37] + +RFC 8141 URNs April 2017 + + +Appendix B. Changes from RFC 2141 + + This document makes substantive changes from the syntax and semantics + of [RFC2141]: + +B.1. Syntax Changes from RFC 2141 + + The syntax of URNs as provided in [RFC2141] was defined before the + updated specification of URIs in [RFC3986]. The definition of URN + syntax is updated in this document to do the following: + + o Ensure consistency with the URI syntax. + + o Facilitate the use of URNs with parameters similar to URI queries + and fragments. + + o Permit parameters influencing URN resolution. + + o Ease the use of URNs with non-URN identifier systems that include + the "/" character. + + In particular, this specification does the following: + + o Extends URN syntax to explicitly allow the characters "/", "?", + and "#", which were reserved for future use by RFC 2141. This + change also effectively allows several components of the URI + syntax although without necessarily tying those components to URI + semantics. + + o Defines general syntax for an additional component that can be + used in interactions with a URN resolution service. + + o Disallows "-" at the end of the NID. + + o Allows the "/", "~", and "&" characters in the NSS. + + o Makes several smaller syntax adjustments. + + + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 38] + +RFC 8141 URNs April 2017 + + +B.2. Other Changes from RFC 2141 + + o Formally registers "urn" as a URI scheme. + + o Allows what are now called r-components, q-components, and + f-components. + + In addition, some of the text has been updated to be consistent with + the definition of URIs [RFC3986] and the processes for registering + information with the IANA [RFC5226], as well as more modern guidance + with regard to security [RFC3552], privacy [RFC6973], and identifier + comparison [RFC6943]. + +Appendix C. Changes from RFC 3406 + + This document makes the following substantive changes from [RFC3406]: + + 1. Relaxes the registration policy for formal URN namespaces from + "IETF Review" to "Expert Review" as discussed in Section 6.2. + + 2. Removes the category of experimental URN namespaces, consistent + with [RFC6648]. Experimental URN namespaces were denoted by + prefixing the namespace identifier with the string "X-". Because + experimental URN namespaces were never registered, removing the + experimental category has no impact on the existing registries. + Because experimental URN namespaces are not managed, strings + conforming to URN syntax within experimental URN namespaces are + not valid URNs. Truly experimental usages may, of course, employ + the "example" namespace [RFC6963]. + + 3. Adds some information to, but generally simplifies, the URN + namespace registration template. + + + + + + + + + + + + + + + + + + + +Saint-Andre & Klensin Standards Track [Page 39] + +RFC 8141 URNs April 2017 + + +Acknowledgements + + Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha + Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean + Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian + Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other + participants in the URNBIS working group for their input. Alfred + Hoenes in particular edited an earlier draft version of this document + and served as co-chair of the URNBIS working group. + + Juha Hakala deserves special recognition for his dedication to + successfully completing this work, as do Andrew Newton and Melinda + Shore in their roles as working group co-chairs and Barry Leiba in + his role as area director and then as co-chair. + +Contributors + + RFC 2141, which provided the basis for the syntax portion of this + document, was authored by Ryan Moats. + + RFC 3406, which provided the basis for the namespace portion of this + document, was authored by Leslie Daigle, Dirk-Willem van Gulik, + Renato Iannella, and Patrik Faltstrom. + + Their work is gratefully acknowledged. + +Authors' Addresses + + Peter Saint-Andre + Filament + P.O. Box 787 + Parker, CO 80134 + United States of America + + Phone: +1 720 256 6756 + Email: peter@filament.com + URI: <https://filament.com/> + + + John C. Klensin + 1770 Massachusetts Ave, Ste 322 + Cambridge, MA 02140 + United States of America + + Phone: +1 617 245 1457 + Email: john-ietf@jck.com + + + + + +Saint-Andre & Klensin Standards Track [Page 40] + |