idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3406, but the abstract doesn't seem to directly say this. It does mention RFC3406 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2141, but the abstract doesn't seem to directly say this. It does mention RFC2141 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2017) is 2606 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 1808 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3044 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 7613 (Obsoleted by RFC 8265) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 URNBIS P. Saint-Andre 3 Internet-Draft Filament 4 Obsoletes: 2141, 3406 (if approved) J. Klensin 5 Intended status: Standards Track 6 Expires: September 3, 2017 March 2, 2017 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-22 11 Abstract 13 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 14 that is assigned under the "urn" URI scheme and a particular URN 15 namespace, with the intent that the URN will be a persistent, 16 location-independent resource identifier. With regard to URN syntax, 17 this document defines the canonical syntax for URNs (in a way that is 18 consistent with URI syntax), specifies methods for determining URN- 19 equivalence, and discusses URI conformance. With regard to URN 20 namespaces, this document specifies a method for defining a URN 21 namespace and associating it with a namespace identifier, and 22 describes procedures for registering namespace identifiers with the 23 Internet Assigned Numbers Authority (IANA). This document obsoletes 24 both RFC 2141 and RFC 3406. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 3, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . 6 63 1.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 7 64 1.2.2. Character Sets and Encodings . . . . . . . . . . . . 8 65 2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.1. Namespace Identifier (NID) . . . . . . . . . . . . . . . 10 67 2.2. Namespace Specific String (NSS) . . . . . . . . . . . . . 10 68 2.3. Optional Components . . . . . . . . . . . . . . . . . . . 11 69 2.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 11 70 2.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 12 71 2.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 14 72 3. URN-Equivalence . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 17 77 4.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.3. URNs and Relative References . . . . . . . . . . . . . . 18 79 4.4. Transport and Display . . . . . . . . . . . . . . . . . . 19 80 4.5. URI Design and Ownership . . . . . . . . . . . . . . . . 19 81 5. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 19 82 5.1. Formal URN Namespaces . . . . . . . . . . . . . . . . . . 21 83 5.2. Informal URN Namespaces . . . . . . . . . . . . . . . . . 23 84 6. Defining and Registering a URN Namespace . . . . . . . . . . 23 85 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 86 6.2. Registration Policy and Process: Community Registrations 24 87 6.3. Registration Policy and Process: Fast Track for Standards 88 Development Organizations, Scientific Societies, and 89 Similar Bodies . . . . . . . . . . . . . . . . . . . . . 25 90 6.4. Completing the Template . . . . . . . . . . . . . . . . . 26 91 6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 26 92 6.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 27 93 6.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 28 94 6.4.4. Security and Privacy . . . . . . . . . . . . . . . . 28 95 6.4.5. Interoperability . . . . . . . . . . . . . . . . . . 29 96 6.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 29 97 6.4.7. Additional Information . . . . . . . . . . . . . . . 29 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 99 7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 30 100 7.2. Registration of URN Namespaces . . . . . . . . . . . . . 30 101 7.3. Discussion list for new and updated NID registrations . . 31 102 8. Security and Privacy Considerations . . . . . . . . . . . . . 31 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 105 9.2. Informative References . . . . . . . . . . . . . . . . . 31 106 Appendix A. Registration Template . . . . . . . . . . . . . . . 35 107 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 36 108 B.1. Syntax changes from RFC 2141 . . . . . . . . . . . . . . 36 109 B.2. Other changes from RFC 2141 . . . . . . . . . . . . . . . 37 110 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 37 111 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 37 112 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 38 113 Appendix F. Change log for versions of draft-ietf-urnbis- 114 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 38 115 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 38 116 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 39 117 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 39 118 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 39 119 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 40 120 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 40 121 F.7. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 40 122 F.8. Changes from -15 (2016-02-04) to -16 . . . . . . . . . . 41 123 F.9. Changes from -16 (2016-04-16) to -17 . . . . . . . . . . 41 124 F.10. Changes from -17 (2016-06-27) to -18 . . . . . . . . . . 42 125 F.11. Changes from -18 (2016-09-05) to -19 . . . . . . . . . . 42 126 F.12. Changes from -19 (2016-12-31) to -20 . . . . . . . . . . 43 127 F.13. Changes from -20 (2017-02-02) to -21 . . . . . . . . . . 43 128 F.14. Changes from -21 (2017-02-27) to -22 . . . . . . . . . . 43 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 131 1. Introduction 133 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 134 [RFC3986] that is assigned under the "urn" URI scheme and a 135 particular URN namespace, with the intent that the URN will be a 136 persistent, location-independent resource identifier. A URN 137 namespace is a collection of such URNs, each of which is (1) unique, 138 (2) assigned in a consistent and managed way, and (3) assigned 139 according to a common definition. (Some URN namespaces create names 140 that exist only as URNs, whereas others assign URNs based on names 141 that were already created in non-URN identifier systems, such as 142 ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].) 143 The assignment of URNs is done by an organization (or, in some cases, 144 according to an algorithm or other automated process) that has been 145 formally delegated a URN namespace within the "urn" scheme (e.g., a 146 URN in the 'example' URN namespace [RFC6963] might be of the form 147 "urn:example:foo"). 149 This document rests on two key assumptions: 151 1. Assignment of a URN is a managed process. 153 2. The space of URN namespaces is itself managed. 155 While other URI schemes may allow resource identifiers to be freely 156 chosen and assigned, such is not the case for URNs. The syntactical 157 correctness of a name starting with "urn:" is not sufficient to make 158 it a URN. In order for the name to be a valid URN, the namespace 159 identifier (NID) needs to be registered in accordance with the rules 160 defined here and the remaining parts of the assigned-name portion of 161 the URN need to be generated in accordance with the rules for the 162 registered URN namespace. 164 So that information about both URN syntax and URN namespaces is 165 available in one place, this document does the following: 167 1. Defines the canonical syntax for URNs in general (in a way that 168 is consistent with URI syntax), specifies methods for determining 169 URN-equivalence, and discusses URI conformance. 171 2. Specifies a method for defining a URN namespace and associating 172 it with a namespace identifier (NID), and describes procedures 173 for registering URN NIDs with the Internet Assigned Numbers 174 Authority (IANA). 176 For URN syntax and URN namespaces, this document modernizes and 177 replaces the original specifications for URN syntax [RFC2141] and for 178 the definition and registration of URN namespaces [RFC3406]. These 179 modifications build on the key requirements provided in the original 180 functional description for URNs [RFC1737] and on the lessons of many 181 years of experience. In those original documents and in the present 182 one, the intent is to define URNs in a consistent manner so that, 183 wherever practical, the parsing, handling, and resolution of URNs can 184 be independent of the URN namespace within which a given URN is 185 assigned. 187 Together with input from several key user communities, the history 188 and experiences with URNs dictated expansion of the URN definition to 189 support new functionality, including the use of syntax explicitly 190 reserved for future standardization in RFC 2141. All URN namespaces 191 and URNs that were valid under the earlier specifications remain 192 valid even though it may be useful to update some of them to take 193 advantage of new features. 195 The foregoing considerations, together with various differences 196 between URNs and URIs that are locators (specifically URLs) as well 197 as the greater focus on URLs in RFC 3986 as the ultimate successor to 198 [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 199 and this specification that appear (or perhaps actually are) not 200 completely consistent, especially with regard to actions or semantics 201 other than the basic syntax itself. If such situations arise, 202 discussions of URNs and URN namespaces should be interpreted 203 according to this document and not by extrapolation from RFC 3986. 205 Summaries of changes from RFC 2141 and RFC 3406 appear in Appendix B 206 and Appendix C respectively. This document obsoletes both [RFC2141] 207 and [RFC3406]. While it does not explicitly update or replace 208 [RFC1737] or [RFC2276], the reader who references those documents 209 should be aware that the conceptual model of URNs in this document is 210 slightly different from those older specifications. 212 1.1. Terminology 214 The following terms are distinguished from each other as described 215 below: 217 URN: A URI (as defined in RFC 3986) using the "urn" scheme and with 218 the properties of a "name" as described in that document as well 219 as the properties described in this one. The term applies to the 220 entire URI including its optional components. Note to the reader: 221 the term "URN" has been used in other contexts to refer to a URN 222 namespace, the namespace identifier (NID), the Assigned-name, and 223 to URIs that do not use the "urn" scheme. All but the last of 224 these is described using more specific terminology elsewhere in 225 this document, but, because of those other uses, the term should 226 be used and interpreted with care. 228 Locator: An identifier that provides a means of accessing a 229 resource. 231 Identifier system: A managed collection of names. This document 232 refers to identifier systems outside the context of URNs as "non- 233 URN identifier systems". 235 URN namespace: An identifier system that is associated with a URN 236 namespace identifier (NID). 238 NID: The identifier associated with a URN namespace. 240 NSS: The URN-namespace-specific part of a URN. 242 Assigned-name: The combination of the 'urn:' scheme, the NID, and 243 the NSS. An "Assigned-name" is consequently a substring of a URN 244 (as defined above) if that URN contains any additional components 245 (see Section 2). 247 The term "name" is deliberately not defined here and should be (and 248 in practice, is) used only very informally. RFC 3986 uses the term 249 as a category of URI distinguished from "locator" (Section 1.1.3) but 250 also uses it in other contexts. If those uses are treated as 251 definitions, they conflict with, e.g., the idea of the name of a URN 252 namespace, i.e., a NID or terms associated with non-URN identifier 253 systems. 255 This document uses the terms "resource", "identifier", "identify", 256 "dereference", "representation", and "metadata" roughly as defined in 257 the URI specification [RFC3986]. 259 This document uses the terms "resolution" and "resolver" in roughly 260 the sense in which they were used in the original discussion of 261 architectural principles for URNs [RFC2276], i.e., "resolution" is 262 the act of supplying services related to the identified resource, 263 such as translating the persistent URN into one or more current 264 locators for the resource, delivering metadata about the resource in 265 an appropriate format, or even delivering a representation of the 266 resource (e.g., a document) without requiring further intermediaries. 267 At the time of this writing, resolution services are described in 268 [RFC2483]. 270 On the distinction between representations and metadata, see 271 Section 1.2.2 of [RFC3986]. 273 Several other terms related to "normalization" operations that are 274 not part of the Unicode Standard [UNICODE] are also used here as they 275 are in RFC 3986. 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in 280 [RFC2119]. 282 1.2. Design Tradeoffs 284 To a degree much greater than when URNs were first considered and 285 their uses outlined (see [RFC1737]), issues of persistent identifiers 286 on the Internet involve fundamental design tradeoffs that are much 287 broader than URNs or the URN approach, and even touch on open 288 research questions within the information sciences community. Ideal 289 and comprehensive specifications about what should be done or 290 required across the entire universe of URNs would require general 291 agreement about, and solutions to, a wide range of such issues. 292 Although some of those issues were introduced by the Internet or 293 computer-age approaches to character encodings and data abstraction, 294 others predate the Internet and computer systems by centuries; there 295 is unlikely to be agreement about comprehensive solutions in the near 296 future. 298 Although this specification consequently contains some requirements 299 and flexibility that would not be present in a more perfect world, 300 this has been necessary in order to produce a consensus specification 301 that provides a modernized definition of URNs (the unattractive 302 alternative would have been to not modernize the definition in spite 303 of widespread deployment). 305 The following sub-sections describe two of the relevant issues in 306 greater detail. 308 1.2.1. Resolution 310 One issue that is specific to URNs (as opposed to naming systems in 311 general) is the fairly difficult topic of "resolution", discussed in 312 Section 1.1, Section 2.3.1, Section 6.4.6, and elsewhere below. 314 With traditional Uniform Resource Locators (URLs), i.e., with most 315 URIs that are locators, resolution is relatively straightforward 316 because it is used to determine an access mechanism which in turn is 317 used to dereference the locator by (typically) retrieving a 318 representation of the associated resource, such as a document (see 319 Section 1.2.2 of [RFC3986]). 321 By contrast, resolution for URNs is more flexible and varied. 323 One important case involves the mapping of a URN to one or more 324 locators. In this case, the end result is still a matter of 325 dereferencing the mapped locator(s) to one or more representations. 326 The primary difference here is persistence: even if a mapped locator 327 has changed (e.g., a DNS domain name has changed hands and a URL has 328 not been modified to point to a new location or, in a more extreme 329 and hypothetical case, the DNS is replaced entirely), a URN user will 330 be able to obtain the correct representation (e.g., a document) as 331 long as the resolver has kept its URN-to-locator mappings up to date. 332 Consequently, the relevant relationships can be defined quite 333 precisely for URNs that resolve to locators which in turn are 334 dereferenced to a representation. 336 However, this specification permits several other cases of URN 337 resolution as well as URNs for resources that do not involve 338 information retrieval systems. This is true either individually for 339 particular URNs or (as defined below) collectively for entire URN 340 namespaces. 342 Consider a namespace of URNs that resolve to locators which in turn 343 are dereferenced only to metadata about resources because the 344 underlying systems contain no representations of those resources; an 345 example might be a URN namespace for International Standard Name 346 Identifiers (ISNI) as that identifier system is defined in the 347 relevant standard [ISO.27729.2012], wherein by default a URN would be 348 resolved only to a metadata record describing the public identity 349 identified by the ISNI. 351 Consider also URNs that resolve to representations only if the 352 requesting entity is authorized to obtain the representation, whereas 353 other entities can obtain only metadata about the resource; an 354 example might be documents held within the legal depository 355 collection of a national library. 357 Finally, some URNs might not be intended to resolve to locators at 358 all; examples might include URNs identifying XML namespace names 359 (e.g., the 'dgiwg' URN namespace specified by [RFC6288]), URNs 360 identifying application features that can be supported within a 361 communications protocol (e.g., the 'alert' URN namespace specified by 362 [RFC7462]), and URNs identifying enumerated types such as values in a 363 registry (e.g., a URN namespace could be used to individually 364 identify the values in all IANA registries, as provisionally proposed 365 in [I-D.saintandre-iana-urn]). 367 Various types of URNs and multiple resolution services which may be 368 available for them leave the concept of "resolution" more complicated 369 but also much richer for URNs than the straightforward case of 370 resolution to a locator that is dereferenced to a representation. 372 1.2.2. Character Sets and Encodings 374 A similar set of considations apply to character sets and encodings. 375 URNs, especially URNs that will be used as user-facing identifiers, 376 should be convenient to use in local languages and writing systems, 377 easily specified with a wide range of keyboards and local 378 conventions, and unambiguous. There are tradeoffs among those goals 379 and it is impossible at present to see how a simple and readily- 380 understandable set of rules could be developed that would be optimal, 381 or even reasonable, for all URNs. The discussion in Section 2.2 382 defines an overall framework that should make generalized parsing and 383 processing possible, but also makes recommendations about rules for 384 individual URN namespaces. 386 2. URN Syntax 388 As discussed above, the syntax for URNs in this specification allows 389 significantly more functionality than was the case in the earlier 390 specifications, most recently [RFC2141]. It is also harmonized with 391 the general URI syntax [RFC3986] (which, it must be noted, was 392 completed after the earlier URN specifications). 394 However, this specification does not extend the URN syntax to allow 395 direct use of characters outside the ASCII range [RFC20]. That 396 restriction implies that any such characters need to be percent- 397 encoded as described in Section 2.1 of the URI specification 398 [RFC3986]. 400 The basic syntax for a URN is defined using the Augmented Backus-Naur 401 Form (ABNF) as specified in [RFC5234]. Rules not defined here 402 (specifically: alphanum, fragment, and pchar) are defined as part of 403 the URI syntax [RFC3986] and used here to point out the syntactic 404 relationship with the terms used there. The definitions of some of 405 the terms used below are not comprehensive; additional restrictions 406 are imposed by the prose that can be found in sections of this 407 document that are specific to those terms (especially r-component in 408 Section 2.3.1 and q-component in Section 2.3.2). 410 namestring = assigned-name 411 [ rq-components ] 412 [ "#" f-component ] 413 assigned-name = "urn" ":" NID ":" NSS 414 NID = (alphanum) 0*30(ldh) (alphanum) 415 ldh = alphanum / "-" 416 NSS = pchar *(pchar / "/") 417 rq-components = [ "?+" r-component ] 418 [ "?=" q-component ] 419 r-component = pchar *( pchar / "/" / "?" ) 420 q-component = pchar *( pchar / "/" / "?" ) 421 f-component = fragment 423 The question mark character "?" can be used without percent-encoding 424 inside r-components, q-components, and f-components. Other than 425 inside those components a "?" that is not immediately followed by "=" 426 or "+" is not defined for URNs and SHOULD be treated as a syntax 427 error by URN-specific parsers and other processors. 429 The following sections provide additional information about the 430 syntactic elements of URNs. 432 2.1. Namespace Identifier (NID) 434 Namespace identifiers (NIDs) are case insensitive (e.g., "ISBN" and 435 "isbn" are equivalent). 437 Characters outside the ASCII range [RFC20] are not permitted in NIDs, 438 and no encoding mechanism for such characters is supported. 440 Section 5.1 and Section 5.2 impose additional constraints on the 441 strings that can be used as NIDs, i.e., the syntax shown above is not 442 comprehensive. 444 2.2. Namespace Specific String (NSS) 446 The namespace specific string (NSS) is a string, unique within a URN 447 namespace, that is assigned and managed in a consistent way and that 448 conforms to the definition of the relevant URN namespace. The 449 combination of the NID (unique across the entire "urn" scheme) and 450 the NSS (unique within the URN namespace) ensures that the resulting 451 URN is globally unique. 453 The NSS as specified in this document allows several characters not 454 permitted by earlier specifications (see Appendix B). In particular, 455 the "/" character, which is now allowed, effectively makes it 456 possible to encapsulate hierarchical names from non-URN identifier 457 systems. For instance, consider the hypothetical example of a 458 hierarchical identifier system in which the names take the form of a 459 sequence of numbers separated by the "/" character, such as "1/406/ 460 47452/2". If the authority for such names were to use URNs, it would 461 be natural to place the existing name in the NSS, resulting in URNs 462 such as "urn:example:1/406/47452/2". 464 Those changes to the syntax for the NSS do not modify the encoding 465 rules for URN namespaces that were defined in accordance with 466 [RFC2141]. If any such URN namespace whose names are used outside of 467 the URN context (i.e., in a non-URN identifier system) also allows 468 the use of "/", "~", or "&" in the native form within that identifier 469 system, then the encoding rules for that URN namespace are not 470 changed by this specification. 472 Depending on the rules governing a non-URN identifier system and its 473 associated URN namespace, names that are valid in that identifier 474 system might contain characters that are not allowed by the "pchar" 475 production referenced above (e.g., characters outside the ASCII range 476 or, consistent with the restrictions in RFC 3986, the characters "/", 477 "?", "#", "[", and "]"). While such a name might be valid within the 478 non-URN identifier system, it is not a valid URN until it has been 479 translated into an NSS that conforms to the rules of that particular 480 URN namespace. In the case of URNs that are formed from names that 481 exist separately in a non-URN identifier system, translation of a 482 name from its "native" format to URN format is accomplished by using 483 the canonicalization and encoding methods defined for URNs in general 484 or specific rules for that URN namespace. Software that is not aware 485 of namespace-specific canonicalization and encoding rules MUST NOT 486 construct URNs from the name in the non-URN identifier system. 488 In particular, with regard to characters outside the ASCII range, 489 URNs that appear in protocols or that are passed between systems MUST 490 use only Unicode characters encoded in UTF-8 and further encoded as 491 required by RFC 3986. To the extent feasible consistent with the 492 requirements of names defined and standardized elsewhere, as well as 493 the principles discussed in Section 1.2, the characters used to 494 represent names SHOULD be restricted to either ASCII letters and 495 digits or to the characters and syntax of some widely-used model such 496 as those of IDNA [RFC5890], PRECIS [RFC7613], or the Unicode 497 Identifier and Pattern Syntax specification [UAX31]. 499 In order to make URNs as stable and persistent as possible when 500 protocols evolve and the environment around them changes, URN 501 namespaces SHOULD NOT allow characters outside the ASCII range 502 [RFC20] unless the nature of the particular URN namespace makes such 503 characters necessary. 505 2.3. Optional Components 507 This specification includes three optional components in the URN 508 syntax. They are known as r-component, q-component, and f-component 509 and are described in more detail below. Because this specification 510 focuses almost exclusively on URN syntax, it does not define detailed 511 semantics of these components for URNs in general. However, each of 512 these components has a distinct role that is independent of any given 513 URN and its URN namespace. It is intended that clients will be able 514 to handle these components uniformly for all URNs. These components 515 MAY be used with URNs from existing URN namespaces, whether or not a 516 URN namespace explicitly supports them. However, consistent with the 517 approach taken in RFC 3986, the behavior of a URN that contains 518 components that are undefined or meaningless for a particular URN 519 namespace or resource is not defined. The following sections 520 describe these optional components and their interpretation in 521 greater detail. 523 2.3.1. r-component 525 The r-component is intended for passing parameters to URN resolution 526 services (taken broadly, see Section 1.2) and interpreted by those 527 services. (By contrast, passing parameters to the resources 528 identified by a URN, or to applications that manage such resources, 529 is handled by q-components as described in the next section.) 531 The URN r-component has no syntactic counterpart in any other known 532 URI scheme. 534 The sequence "?+" introduces the r-component. The r-component ends 535 with a "?=" sequence (which begins a q-component) or a "#" character 536 (number sign, which begins an f-component). If neither of those 537 appear, the r-component continues to the end of the URN. Note that 538 characters outside the ASCII range [RFC20] MUST be percent-encoded 539 using the method defined in Section 2.1 of the generic URI 540 specification [RFC3986]. 542 As described under Section 3, the r-component SHALL NOT be taken into 543 account when determining URN-equivalence. However, the r-component 544 SHALL be supplied along with the URN when presenting a request to a 545 URN resolution service. 547 This document defines only the syntax of the r-component and reserves 548 it for future use. The exact semantics of the r-component and its 549 use in URN resolution protocols are a matter for potential 550 standardization in separate specifications, presumably including 551 specifications that define conventions and a registry for resolution 552 service identifiers. 554 Consider the hypothetical example of passing parameters to a 555 resolution service (say, an ISO alpha-2 country code [ISO.3166-1] in 556 order to select the preferred country in which to search for a 557 physical copy of a book). This could perhaps be accomplished by 558 specifying the country code in the r-component, resulting in URNs 559 such as: 561 urn:example:foo-bar-baz-qux?+CCResolve:cc=uk 563 While the above should serve as a general explanation and 564 illustration of the intent for r-components, there are many open 565 issues with them, including their relationship to resolution 566 mechanisms associated with the particular URN namespace at 567 registration time. Thus r-components SHOULD NOT be used for URNs 568 before their semantics have been standardized. 570 2.3.2. q-component 572 The q-component is intended for passing parameters to either the 573 named resource or a system that can supply the requested service, for 574 interpretation by that resource or system. (By contrast, passing 575 parameters to URN resolution services is handled by r-components as 576 described in the previous section.) 578 The URN q-component has the same syntax as the URI query component, 579 but is introduced by "?=", not "?" alone. For a URN that may be 580 resolved to a URI that is a locator, the semantics of the q-component 581 are identical to those for the query component of that URI. Thus URN 582 resolvers returning a URI that is a locator for a URN with a 583 q-component do this by copying the q-component from the URN to the 584 query component of the URI. An example of the copying operation 585 appears below. 587 This specification does not specify a required behavior in the case 588 of URN resolution to a URI that is a locator when the original URN 589 has a q-component and the URI has a query string. Different 590 circumstance may require different approaches. Resolvers SHOULD 591 document their strategy in such cases. 593 If the URN does not resolve to a URI that is a locator, the 594 interpretation of the q-component is undefined by this specification. 595 For URNs which may be resolved to a URI that is a locator, the 596 semantics of the q-component are identical to those for queries to 597 the resource located via that URI. 599 For the sake of consistency with RFC 3986, the general syntax and the 600 semantics of q-components are not defined by, or dependent on, the 601 URN namespace of the URN. In parallel with RFC 3986, specifics of 602 syntax and semantics, e.g., which keywords or terms are meaningful, 603 of course may depend on a particular URN namespace or even a 604 particular resource. 606 The sequence "?=" introduces the q-component. The q-component 607 terminates when a "#" character (number sign, which begins an 608 f-component) appears. If that character does not appear, the 609 q-component continues to the end of the URN. The characters slash (" 610 /") and question mark ("?") may represent data within the 611 q-component. Note that characters outside the ASCII range [RFC20] 612 MUST be percent-encoded using the method defined in Section 2.1 of 613 the generic URI specification [RFC3986]. 615 As described in Section 3, the q-component SHALL NOT be taken into 616 account when determining URN-equivalence. 618 URN namespaces and associated information placement in syntax SHOULD 619 be designed to avoid any need for a resolution service to consider 620 the q-component. Namespace-specific and more generic resolution 621 systems MUST NOT require that q-component information be passed to 622 them for processing. 624 Consider the hypothetical example of passing parameters to an 625 application that returns weather reports from different regions or 626 for different time periods. This could perhaps be accomplished by 627 specifying latitude and longitude coordinates and datetimes in the 628 URN's q-component, resulting in URNs such as the following. 630 urn:example:weather?=op=map&lat=39.56 631 &lon=-104.85&datetime=1969-07-21T02:56:15Z 633 If this example resolved to an HTTP URI, the result might look like: 635 https://weatherapp.example?op=map&lat=39.56 636 &lon=-104.85&datetime=1969-07-21T02:56:15Z 638 2.3.3. f-component 640 The f-component is intended to be interpreted by the client as a 641 specification for a location within, or region of, the named 642 resource. It distinguishes the constituent parts of a resource named 643 by a URN. For a URN that resolves to one or more locators which can 644 be dereferenced to a representation, or where the URN resolver 645 directly returns a representation of the resource, the semantics of 646 an f-component are defined by the media type of the representation. 648 The URN f-component has the same syntax as the URI fragment 649 component. If a URN containing an f-component resolves to a single 650 URI that is a locator associated with the named resource, the 651 f-component from the URN can be applied (usually by the client) as 652 the fragment of that URI. If the URN does not resolve to a URI that 653 is a locator, the interpretation of the f-component is undefined by 654 this specification. Thus, for URNs which may be resolved to a URI 655 that is a locator, the semantics of f-components are identical to 656 those of fragments for that resource. 658 For the sake of consistency with RFC 3986, neither the general syntax 659 nor the semantics of f-components are defined by, or dependent on, 660 the URN namespace of the URN. In parallel with RFC 3986, specifics 661 of syntax and semantics, e.g., which keywords or terms are 662 meaningful, of course may depend on a particular URN namespace or 663 even a particular resource. 665 The f-component is introduced by the number sign ("#") character and 666 terminated by the end of the URI. Any characters outside the ASCII 667 range [RFC20] that appear in the f-component MUST be percent-encoded 668 using the method defined in Section 2.1 of the generic URI 669 specification [RFC3986]. 671 As described under Section 3, the f-component SHALL NOT be taken into 672 account when determining URN-equivalence. 674 Clients SHOULD NOT pass f-components to resolution services unless 675 those services also perform object retrieval and interpretation 676 functions. 678 Consider the hypothetical example of obtaining resources that are 679 part of a larger entity (say, the chapters of a book). Each part 680 could be specified in the f-component, resulting in URNs such as: 682 urn:example:foo-bar-baz-qux#somepart 684 3. URN-Equivalence 686 3.1. Procedure 688 For various purposes such as caching, it is often desirable to 689 determine if two URNs are "the same". This is done most generally 690 (i.e., independent of the scheme) by testing for equivalence (see 691 Section 6.1 of [RFC3986]). 693 The generic URI specification [RFC3986] is very flexible about 694 equality comparisons, putting the focus on allowing false negatives 695 and avoiding false positives. If comparisons are made in a scheme- 696 independent way, i.e., as URI comparisons only, many URNs that this 697 specification considers equal would be rejected. The discussion 698 below applies when the URIs involved are known to be URNs, and thus 699 uses the terms "URN-equivalent" and "URN-equivalence" to refer to 700 equivalence as specified in this document. 702 Two URNs are URN-equivalent if their portions are 703 octet-by-octet equal after applying case normalization (as specified 704 in Section 6.2.2.1 of [RFC3986]) to the following constructs: 706 1. the URI scheme "urn", by conversion to lower case 708 2. the NID, by conversion to lower case 710 3. any percent-encoded characters in the NSS (that is, all character 711 triplets that match the production found in 712 Section 2.1 of the base URI specification [RFC3986]), by 713 conversion to upper case for the digits A-F. 715 Percent-encoded characters MUST NOT be decoded, i.e., percent- 716 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 717 MUST NOT be applied as part of the comparison process. 719 If an r-component, q-component, or f-component (or any combination 720 thereof) is included in a URN, it MUST be ignored for purposes of 721 determining URN-equivalence. 723 URN namespace definitions MAY include additional rules for URN- 724 equivalence, such as case-insensitivity of the NSS (or parts 725 thereof). Such rules MUST always have the effect of eliminating some 726 of the false negatives obtained by the procedure above and MUST NOT 727 result in treating two URNs as not "the same" if the procedure here 728 says they are URN-equivalent. For related considerations with regard 729 to NID registration, see below. 731 3.2. Examples 733 This section shows a variety of URNs (using the "example" NID defined 734 in [RFC6963]) that highlight the URN-equivalence rules. 736 First, because the scheme and NID are case-insensitive, the following 737 three URNs are URN-equivalent to each other: 739 o urn:example:a123,z456 741 o URN:example:a123,z456 743 o urn:EXAMPLE:a123,z456 745 Second, because the r-component, q-component, and f-component are not 746 taken into account for purposes of testing URN-equivalence, the 747 following three URNs are URN-equivalent to the first three examples 748 above: 750 o urn:example:a123,z456?+abc 752 o urn:example:a123,z456?=xyz 754 o urn:example:a123,z456#789 756 Third, because the "/" character (and anything that follows it) in 757 the NSS is taken into account for purposes of URN-equivalence, the 758 following URNs are not URN-equivalent to each other or to the six 759 preceding URNs: 761 o urn:example:a123,z456/foo 762 o urn:example:a123,z456/bar 764 o urn:example:a123,z456/baz 766 Fourth, because of percent-encoding, the following URNs are URN- 767 equivalent only to each other and not to any of those above (note 768 that, although %2C is the percent-encoded transformation of "," from 769 the previous examples, such sequences are not decoded for purposes of 770 testing URN-equivalence): 772 o urn:example:a123%2Cz456 774 o URN:EXAMPLE:a123%2cz456 776 Fifth, because characters in the NSS other than percent-encoded 777 sequences are treated in a case-sensitive manner (unless otherwise 778 specified for the URN namespace in question), the following URNs are 779 not URN-equivalent to the first three URNs: 781 o urn:example:A123,z456 783 o urn:example:a123,Z456 785 Sixth, on casual visual inspection of a URN presented in a human- 786 oriented interface the following URN might appear the same as the 787 first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be 788 confused with U+0061 LATIN SMALL LETTER A), but it is not URN- 789 equivalent to the first three URNs: 791 o urn:example:%D0%B0123,z456 793 4. URI Conformance 795 4.1. Use in URI Protocol Slots 797 Because a URN is, syntactically, a URI under the "urn" scheme, in 798 theory a URN can be placed in any protocol slot that allows for a URI 799 (to name just a few, the 'href' and 'src' attributes in HTML, the 800 element in HTML, the 'xml:base' attribute in XML [XML-BASE], 801 and the 'xmlns' attribute in XML for XML namespace names 802 [XML-NAMES]). 804 However, this does not imply that, semantically, it always makes 805 sense in practice to place a URN in a given URI protocol slot; in 806 particular, because a URN might not specify the location of a 807 resource or even point indirectly to one, it might not be appropriate 808 to place a URN in a URI protocol slot that points to a resource 809 (e.g., the aforementioned 'href' and 'src' attributes). 811 Ultimately, guidelines regarding when it is appropriate to use URIs 812 under the "urn" scheme (or any other scheme) are the responsibility 813 of specifications for individual URI protocol slots (e.g., the 814 specification for the 'xml:base' attribute in XML might recommend 815 that it is inappropriate to use URNs in that protocol slot). This 816 specification cannot possibly anticipate all of the relevant cases, 817 and it is not the place of this specification to require or restrict 818 usage for individual protocol slots. 820 4.2. Parsing 822 In part because of the separation of URN semantics from more general 823 URI syntax, generic URI processors need to pay special attention to 824 the parsing and analysis rules of RFC 3986 and, in particular, must 825 treat the URI as opaque unless the scheme and its requirements are 826 recognized. In the latter case, such processors may be in a position 827 to invoke scheme-appropriate processing, e.g., by a URN resolver. A 828 URN resolver can either be an external resolver that the URI resolver 829 knows of, or it can be functionality built into the URI resolver. 830 Note that this requirement might impose constraints on the contexts 831 in which URNs are appropriately used; see Section 4.1. 833 4.3. URNs and Relative References 835 Section 5.2 of [RFC3986] describes an algorithm for converting a URI 836 reference that might be relative to a given base URI into "parsed 837 components" of the target of that reference, which can then be 838 recomposed per RFC 3986 Section 5.3 into a target URI. This 839 algorithm is problematic for URNs because their syntax does not 840 support the necessary path components. However, if the algorithm is 841 applied independent of a particular scheme, it should work 842 predictably for URNs as well, with the following understandings 843 (syntax production terminology taken from RFC 3986): 845 1. A system that encounters a that obeys the syntax 846 for , whether it explicitly has the scheme "urn" or 847 not, will convert it into a target URI as specified in RFC 3986. 849 2. Because of the persistence and stability expectations of URNs, 850 authors of documents, etc., that utilize URNs should generally 851 avoid the use of the "urn" scheme in any that is 852 not strictly a as specified in RFC 3986, specifically 853 including those that would require processing of . 855 4.4. Transport and Display 857 When URNs are transported and exchanged, they MUST be represented in 858 the format defined herein. Further, URN-aware applications are 859 strongly encouraged to offer the option of displaying URNs in this 860 canonical form to allow for direct transcription (for example by 861 copy-and-paste techniques). Such applications might support display 862 of URNs in a more human-friendly form and might use a character set 863 that includes characters that are not permitted in URN syntax as 864 defined in this specification (e.g., when displaying URNs to humans, 865 such applications might replace percent-encoded strings with 866 characters from an extended character repertoire such as Unicode 867 [UNICODE]). 869 To minimize user confusion, any application displaying URIs SHOULD 870 display the complete URI (including, for URNs, the "urn" scheme and 871 any components) to ensure that there is no confusion between URN NIDs 872 and URI scheme identifiers. For example, a URI beginning with 873 "urn:xmpp:" [RFC4854] is very different from a URI beginning with 874 "xmpp:" [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] 875 is different from, and possibly completely unrelated to, a possible 876 DOI URN namespace. 878 4.5. URI Design and Ownership 880 As mentioned, the assignment of URNs within a URN namespace is a 881 managed process, as is the assignment of URN namespaces themselves. 882 Although design of the URNs to be assigned within a given URN 883 namespace is ceded by this specification to the URN namespace 884 manager, doing so in a managed way avoids the problems inherent in 885 unmanaged generation of URIs as described in the recommendations 886 regarding URI design and ownership [RFC7320]. 888 5. URN Namespaces 890 A URN namespace is a collection of names that obey three constraints: 891 each name is (1) unique, (2) assigned in a consistent way, and (3) 892 assigned according to a common definition. 894 1. The "uniqueness" constraint means that a name within the URN 895 namespace is never assigned to more than one resource and never 896 reassigned to a different resource (for the kind of "resource" 897 identified by URNs assigned within the URN namespace). This 898 holds true even if the name itself is deprecated or becomes 899 obsolete. 901 2. The "consistent assignment" constraint means that a name within 902 the URN namespace is assigned by an organization or created in 903 accordance with a process or algorithm that is always followed. 905 3. The "common definition" constraint means that there are clear 906 definitions for the syntax of names within the URN namespace and 907 for the process of assigning or creating them. 909 A URN namespace is identified by a particular NID in order to ensure 910 the global uniqueness of URNs and, optionally, to provide a cue 911 regarding the structure of URNs assigned within a URN namespace. 913 With regard to global uniqueness, using different NIDs for different 914 collections of names ensures that no two URNs will be the same for 915 different resources, because each collection is required to uniquely 916 assign each name. However, a single resource MAY have more than one 917 URN assigned to it, either in the same URN namespace (if the URN 918 namespace permits it) or in different URN namespaces, and either for 919 similar purposes or different purposes. (For example, if a publisher 920 assigns an ISBN [RFC3187] to an electronic publication and that 921 publication is later incorporated into a digital long-term archive 922 operated by a national library, the library might assign the 923 publication an NBN [RFC3188], resulting in two URNs referring to the 924 same book.) Subject to other constraints, such as those imposed by 925 the URI syntax [RFC3986], the rules of the URN scheme are intended to 926 allow preserving the normal and natural form of names specified in 927 non-URN identifier systems when they are treated as URNs. 929 With regard to the structure of names assigned within a URN 930 namespace, the development of a naming structure (and thereby a 931 collection of names) depends on the requirements of the community 932 defining the names, how the names will be assigned and used, etc. 933 These issues are beyond the scope of URN syntax and the general rules 934 for URN namespaces, because they are specific to the community 935 defining a non-URN identifier system or a particular URN namespace 936 (e.g., the bibliographic and publishing communities in the case of 937 the 'ISBN' URN namespace [RFC3187] and the 'ISSN' URN namespace 938 [RFC3044], or the developers of extensions to the Extensible 939 Messaging and Presence Protocol [RFC6120] in the case of the 'XMPP' 940 URN namespace [RFC4854]). 942 Because the colon character (":") is used to separate "urn" from the 943 NID and the NID from the NSS, it's tempting to think of the entire 944 URN as being structured by colon characters, and to assume that 945 colons create a structure or hierarchy within the NSS portion of the 946 URN. Such structure could be specified by a particular NID 947 specification, but there is no implicit structure. In a URN such as 948 urn:example:apple:pear:plum:cherry 950 the NSS string is "apple:pear:plum:cherry" as a whole, and there is 951 no specific meaning to the colon characters within that NSS string 952 unless such meaning is described in the specification of the 953 "example" namespace. 955 URN namespaces inherit certain rights and responsibilities by the 956 nature of URNs, in particular: 958 1. They uphold the general principles of a well-managed URN 959 namespace by providing persistent identification of resources and 960 unique assignment of names in accordance with a common 961 definition. 963 2. Optionally, they can be registered in global registration 964 services such as those described in [RFC2483]. 966 There are two types of URN namespace: formal and informal. These are 967 distinguished by the expected level of service, the information 968 needed to define the URN namespace, and the procedures for 969 registration. Because the majority of the URN namespaces registered 970 so far have been formal, this document concentrates on formal URN 971 namespaces. 973 5.1. Formal URN Namespaces 975 A formal URN namespace provides benefit to some subset of users on 976 the Internet. In particular, it would not make sense for a formal 977 URN namespace to be used only by a community or network that is not 978 connected to the Internet. For example, it would be inappropriate 979 for a URN namespace to effectively force someone to use a proprietary 980 network or service not open to the general Internet user. The intent 981 is that, while the community of those who might actively use the URNs 982 assigned within that URN namespace might be small, the potential use 983 of names within that URN namespace is open to any user on the 984 Internet. Formal URN namespaces might be appropriate even when some 985 aspects are not fully open. For example, a URN namespace might make 986 use of a fee-based, privately managed, or proprietary registry for 987 assignment of URNs in the URN namespace. However, it might still 988 benefit some Internet users if the associated services have openly- 989 published names. 991 An organization that will assign URNs within a formal URN namespace 992 SHOULD meet the following criteria: 994 1. Organizational stability and the ability to maintain the URN 995 namespace for a long time; absent such evidence, it ought to be 996 clear how the URN namespace can remain viable if the organization 997 can no longer maintain the URN namespace. 999 2. Competency in URN assignment. This will improve the likelihood 1000 of persistence (e.g., to minimize the likelihood of conflicts). 1002 3. Commitment to not reassigning existing URNs and to allowing old 1003 URNs to continue to be valid (e.g., if the assignee of a URN is 1004 no longer a member or customer of the assigning organization, if 1005 various information about the assignee or named entity happens to 1006 change, or even if the assignee or the named entity itself is no 1007 longer in existence; in all these cases, the URN is still valid). 1009 A formal URN namespace establishes a particular NID, subject to the 1010 following constraints (above and beyond the syntax rules already 1011 specified): 1013 1. It MUST NOT be an already-registered NID. 1015 2. It MUST NOT start with "urn-" (which is reserved for informal URN 1016 namespaces). 1018 3. It MUST be more than two characters long and it MUST NOT start 1019 with ALPHA ALPHA "-", i.e., any string consisting of two letters 1020 followed by one hyphen; such strings are reserved for potential 1021 use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for 1022 eventual national registrations of URN namespaces (however, the 1023 definition and scoping of rules for allocation of responsibility 1024 for such country-code-based URN namespaces are beyond the scope 1025 of this document). As a consequence, it MUST NOT start with the 1026 string "xn--" or any other string consisting of two letters 1027 followed by two hyphens; such strings are reserved for potential 1028 representation of DNS A-labels and similar strings in the future 1029 [RFC5890]. 1031 4. It MUST NOT start with the string "X-" so that it will not be 1032 confused with or conflict any experimental URN namespace 1033 previously permitted by [RFC3406]. 1035 Applicants and reviewers considering new NIDs should also be aware 1036 that they may have semantic implications and hence be a source of 1037 conflict. Particular attention should be paid to strings that might 1038 be construed as identifiers for, or registered under the authority 1039 of, countries (including ISO 3166-1 alpha-3 codes) and to strings 1040 that might imply association with existing URI schemes, non-URN 1041 identifier systems, or trademarks. However, in line with traditional 1042 policies, disputes about "ownership" of particular strings are 1043 disagreements among the parties involved; neither IANA nor the IETF 1044 will become involved in such disputes except in response to orders 1045 from a court of competent jurisdiction. 1047 5.2. Informal URN Namespaces 1049 Informal URN namespaces are full-fledged URN namespaces, with all the 1050 associated rights and responsibilities. Informal URN namespaces 1051 differ from formal URN namespaces in the process for assigning a NID: 1052 for an informal URN namespace, the registrant does not designate the 1053 NID; instead, IANA assigns a NID consisting of the string 'urn-' 1054 followed by one or more digits (e.g., "urn-7") where the digits 1055 consist of the next available number in the sequence of positive 1056 integers assigned to informal URN namespaces. Thus the syntax of an 1057 informal URN namespace identifier is: 1059 InformalNamespaceName = "urn-" Number 1060 Number = DigitNonZero 0*Digit 1061 DigitNonZero = "1"/ "2" / "3" / "4"/ "5" 1062 / "6" / "7" / "8" / "9" 1063 Digit = "0" / DigitNonZero 1065 The only restrictions on are that it (1) consist strictly of 1066 ASCII digits, that it (2) not have leading zeros, and that it (3) not 1067 cause the NID to exceed the length limitations defined for the URN 1068 syntax (see Section 2). 1070 6. Defining and Registering a URN Namespace 1072 6.1. Overview 1074 Because the space of URN namespaces is itself managed, the definition 1075 of a URN namespace SHOULD pay particular attention to: 1077 1. The purpose of the URN namespace. 1079 2. The syntax of URNs assigned within the URN namespace, including 1080 the internal syntax and anticipated effects of r-components or 1081 q-components. (The syntax and interpretation of f-components are 1082 defined in RFC 3986.) 1084 3. The process for assigning URNs within the URN namespace. 1086 4. The security implications of assigning URNs within the URN 1087 namespace and of using the assigned URNs. 1089 5. Any potential interoperability issues with URNs assigned within 1090 the URN namespace. 1092 6. Optionally, the process for resolving URNs issued within the URN 1093 namespace. 1095 The section on completing the template (Section 6.4) explains these 1096 matters in greater detail. Although the registration templates are 1097 the same in all cases, slightly different procedures are used 1098 depending on the source of the registration. 1100 6.2. Registration Policy and Process: Community Registrations 1102 The basic registration policy for URN namespaces is Expert Review as 1103 defined in the "IANA Considerations" document [RFC5226]. For URN 1104 namespaces or their definitions that are intended to become standards 1105 or constituent parts of standards, the output of the Expert Review 1106 process is intended to be a report, rather than instructions to IANA 1107 to take action (see below). The key steps are: 1109 1. Fill out the URN namespace registration template (see Section 6.4 1110 and Appendix A). This can be done as part of an Internet-Draft 1111 or a specification in another series, although that is not a 1112 requirement. 1114 2. Send the completed template to the urn@ietf.org discussion list 1115 for review. 1117 3. If necessary to address comments received, repeat steps 1 and 2. 1119 4. If the designated experts approve the request and no 1120 standardization action is involved, the IANA will register the 1121 requested NID. If standardization is anticipated, the designated 1122 experts will prepare a report and forward it to the appropriate 1123 standards approval body (the IESG in the case of the IETF); IANA 1124 will register the requested NID only after receiving directions 1125 from that body and a copy of the expert review report. 1127 A URN namespace registration can be revised by updating the 1128 registration template, following the same steps outlined above for 1129 new registrations. A revised registration MUST describe differences 1130 from prior versions and SHOULD make special note of any relevant 1131 changes in the underlying technologies or URN namespace management 1132 processes. 1134 Experience to date with URN namespace registration requests has shown 1135 that registrants sometimes do not initially understand some of the 1136 subtleties of URN namespaces, and that defining the URN namespace in 1137 the form of a specification enables the registrants to clearly 1138 formulate their "contract" with the intended user community. 1139 Therefore, although the registration policy for formal URN namespaces 1140 is Expert Review and a specification (as distinct from the 1141 registration template) is not strictly required, registrants SHOULD 1142 provide a stable specification documenting the URN namespace 1143 definition and expanding upon the issues described herein. 1145 Because naming can be difficult and contentious, URN namespace 1146 registrants and the designated experts are strongly encouraged to 1147 work together in a spirit of good faith and mutual understanding to 1148 achieve rough consensus (see [RFC7282]) on handling registration 1149 requests. They are also encouraged to bring additional expertise 1150 into the discussion if that would be helpful in providing perspective 1151 or otherwise resolving issues. 1153 Especially when iterations in the registration process are prolonged, 1154 designated experts are expected to take reasonable precautions to 1155 avoid "race conditions" on proposed NIDs and, if such situations 1156 arise, to encourage applicants to work out any conflicts among 1157 themselves. 1159 6.3. Registration Policy and Process: Fast Track for Standards 1160 Development Organizations, Scientific Societies, and Similar 1161 Bodies 1163 The IETF recognizes that situations will arise in which URN 1164 namespaces will be created to either embed existing and established 1165 standards, particularly identifier standards, or to reflect 1166 knowledge, terminology, or methods of organizing information that lie 1167 well outside the IETF's scope or the likely subject matter knowledge 1168 of its designated experts. In situations in which the registration 1169 request originates from, or is authorized by, a recognized standards- 1170 related organization, scientific society, or similar body, a somewhat 1171 different procedure is available at the option of that body: 1173 1. The URN namespace registration template is filled out and 1174 submitted as in steps 1 and 2 of Section 6.2. 1176 2. A specification is required that reflects or points to the needed 1177 external standards or specifications. Publication in the RFC 1178 Series or through an IETF process (e.g., posting as an Internet 1179 Draft) is not expected and would be appropriate only under very 1180 unusual circumstances. 1182 3. The reviews on the discussion list and by the designated experts 1183 are strictly advisory, with the decisions about what advice to 1184 accept and the length of time to allocate to the process strictly 1185 under the control of the external body. 1187 4. When that body concludes that the application is sufficiently 1188 mature, its representative(s) will request that IANA complete the 1189 registration for the NID, and IANA will do so. 1191 Decisions about whether to recognize the requesting entity as a 1192 standards-related organization, scientific society, or similar body 1193 are the responsibility of the IESG. 1195 A model similar to this has already been defined for recognized 1196 standards-related organizations that wish to register Media Types. 1197 The document describing that mechanism [RFC6838] provides somewhat 1198 more information about the general approach. 1200 6.4. Completing the Template 1202 A template for defining and registering a URN namespace is provided 1203 in Appendix A. This section describes considerations for completing 1204 the template. 1206 6.4.1. Purpose 1208 The "Purpose" section of the template describes matters such as: 1210 1. The kinds of resources identified by URNs assigned within the URN 1211 namespace. 1213 2. The scope and applicability of the URNs assigned within the URN 1214 namespace; this might include information about the community of 1215 use (e.g., a particular nation, industry, technology, or 1216 organization), whether the assigned URNs will be used on public 1217 networks or private networks, etc. 1219 3. How the intended community (and the Internet community at large) 1220 will benefit from using or resolving the assigned URNs. 1222 4. How the URN namespace relates to and complements existing URN 1223 namespaces, URI schemes, and non-URN identifier systems. 1225 5. The kinds of software applications that can use or resolve the 1226 assigned URNs (e.g., by differentiating among disparate URN 1227 namespaces, identifying resources in a persistent fashion, or 1228 meaningfully resolving and accessing services associated with the 1229 URN namespace). 1231 6. Whether resolution services are available or will be available 1232 (and, if so, the nature or identity of the services). Examples 1233 of q-component and (when they are standardized) r-component 1234 semantics and syntax are helpful here, even if detailed 1235 definitions are provided elsewhere or later. 1237 7. Whether the URN namespace or its definition is expected to become 1238 a constituent part of a standard being developed in the IETF or 1239 some other recognized standards body. 1241 6.4.2. Syntax 1243 The "Syntax" section of the template contains: 1245 1. A description of the structure of URNs within the URN namespace, 1246 in conformance with the fundamental URN syntax. The structure 1247 might be described in terms of a formal definition (e.g., using 1248 Augmented BNF for Syntax Specifications (ABNF) [RFC5234]), an 1249 algorithm for generating conformant URNs, or a regular expression 1250 for parsing the name into consituent parts; alternatively, the 1251 structure might be opaque. 1253 2. Any special character encoding rules for assigned URNs (e.g., 1254 which character ought to always be used for quotes). 1256 3. Rules for determining URN-equivalence between two names in the 1257 URN namespace. Such rules ought to always have the effect of 1258 eliminating false negatives that might otherwise result from 1259 comparison. If it is appropriate and helpful, reference can be 1260 made to particular equivalence rules defined in the URI 1261 specification [RFC3986] or to Section 3 of this document. 1262 Examples of URN-equivalence rules include equivalence between 1263 uppercase and lowercase characters in the NSS, between hyphenated 1264 and non-hyphenated groupings in the name, or between single- 1265 quotes and double-quotes. There may also be namespace-specific 1266 special encoding considerations, especially for URNs that contain 1267 embedded forms of names from non-URN identifier systems. (Note 1268 that these are not normative statements for any kind of best 1269 practice related to handling of relationships between characters 1270 in general; such statements are limited to one particular URN 1271 namespace only.) 1273 4. Any special considerations necessary for conforming with the URN 1274 syntax. This is particularly applicable in the case of existing, 1275 non-URN identifier systems that are used in the context of URNs. 1276 For example, if a non-URN identifier system is used in contexts 1277 other than URNs, it might make use of characters that are 1278 reserved in the URN syntax. This section ought to note any such 1279 characters, and outline necessary mappings to conform to URN 1280 syntax. Normally, this will be handled by percent-encoding the 1281 character as specified in Section 2.1 of the URI specification 1283 [RFC3986] and as discussed in Section 1.2.2 of this 1284 specification. 1286 5. Any special considerations for the meaning of q-components (e.g., 1287 keywords) or f-components (e.g., predefined terms) in the context 1288 of this URN namespace. 1290 6.4.3. Assignment 1292 The "Assignment" section of the template describes matters such as: 1294 1. Mechanisms or authorities for assigning URNs to resources. It 1295 ought to make clear whether assignment is completely open (e.g., 1296 following a particular procedure such as first-come, first-served 1297 (FCFS)), completely closed (e.g., for a private organization), or 1298 limited in various ways (e.g., delegated to authorities 1299 recognized by a particular organization); if limited, it ought to 1300 explain how to become an assigner of names or how to request 1301 assignment of names from existing assignment authorities. 1303 2. Methods for ensuring that URNs within the URN namespace are 1304 unique. For example, names might be assigned sequentially or in 1305 accordance with some well-defined process by a single authority, 1306 assignment might be partitioned among delegated authorities that 1307 are individually responsible for respecting uniqueness rules, or 1308 URNs might be created independently following an algorithm that 1309 itself guarantees uniqueness. 1311 6.4.4. Security and Privacy 1313 The "Security and Privacy" section of the template describes any 1314 potential issues related to security and privacy with regard to 1315 assignment, use, and resolution of names within the URN namespace. 1316 Examples of such issues include: 1318 o The consequences of producing false negatives and false positives 1319 during comparison for URN-equivalence (see Section 1.2.2 of this 1320 specification and "Issues in Identifier Comparison for Security 1321 Purposes" [RFC6943]). 1323 o Leakage of private information when names are communicated on the 1324 public Internet. 1326 o The potential for directory harvesting. 1328 o Various issues discussed in the guidelines for security 1329 considerations in RFCs [RFC3552] and the privacy considerations 1330 for Internet protocols [RFC6973]. In particular note the privacy 1331 considerations text for the Global System for Mobile 1332 Communications Association (GSMA) / International Mobile station 1333 Equipment Identity (IMEI) namespace [RFC7254], which may provide a 1334 useful model for such cases. 1336 6.4.5. Interoperability 1338 The "Interoperability" section MUST specify any known potential 1339 issues related to interoperability. Examples include possible 1340 confusion with other URN namespaces, non-URN identifier systems, or 1341 URI schemes because of syntax (e.g., percent-encoding of certain 1342 characters) or scope (e.g., overlapping areas of interest). If at 1343 all possible, concerns that arise during the registration of a URN 1344 namespace (e.g., due to the syntax or scope of a non-URN identifier 1345 system) should be resolved as part of or in parallel to the 1346 registration process. 1348 6.4.6. Resolution 1350 The "Resolution" section MUST specify whether resolution mechanisms 1351 are intended or anticipated for URNs assigned within the URN 1352 namespace. 1354 If resolution is intended, then this section SHOULD specify whether 1355 the organization that assigns URNs within the URN namespace intends 1356 to operate or recommend any resolution services for URNs within that 1357 URN namespace. In addition, if the assigning organization intends to 1358 implement registration for publicly advertised resolution services 1359 (for example using a system based on principles similar to those 1360 described in [RFC2276] and [RFC2483]), then this section SHOULD list 1361 or reference the requirements for being publicly advertised by the 1362 assigning organization. In addition, this section SHOULD describe 1363 any special considerations for the handling of r-components in the 1364 context of this URN namespace. 1366 6.4.7. Additional Information 1368 The "Additional Information" section includes information that would 1369 be useful to those trying to understand this registration or its 1370 relationship to other registrations, such as comparisons to existing 1371 URN namespaces that might seem to overlap. 1373 This section of the template is optional. 1375 7. IANA Considerations 1377 7.1. URI Scheme 1379 This section updates the registration of the 'urn' URI scheme in the 1380 Permanent URI Registry [URI-Registry]. 1382 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 1383 and the number assigned to this document upon publication.] 1385 URI Scheme Name: urn 1387 Status: permanent 1389 URI Scheme Syntax: See Section 2 of [ this document ]. 1391 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 1392 Names, which are persistent, location-independent resource 1393 identifiers. 1395 Encoding Considerations: See Section 2 of [ this document ]. 1397 Applications/Protocols That Use This URI Scheme Name: Uniform 1398 Resource Names are used in a wide variety of applications, 1399 including bibliographic reference systems and as names for 1400 Extensible Markup Language (XML) namespaces. 1402 Interoperability Considerations: See Section 4 of [ this document ]. 1404 Security Considerations: See Section 6.4.4 and Section 8 of [ this 1405 document ]. 1407 Contact: URNBIS WG [mailto:urn@ietf.org] 1409 Author/Change Controller: This scheme is registered under the IETF 1410 tree. As such, the IETF maintains change control. 1412 References None. 1414 7.2. Registration of URN Namespaces 1416 This document outlines the processes for registering URN namespaces, 1417 and has implications for the IANA in terms of registries to be 1418 maintained (see especially Section 6). In all cases, the IANA ought 1419 to assign the appropriate NID (formal or informal) once the 1420 procedures outlined in Section 6 above have been completed. 1422 7.3. Discussion list for new and updated NID registrations 1424 As discussed elsewhere in this document, the discussion list, urn- 1425 nid@apps.ietf.org, specified in RFC 3406 is discontinued and [[should 1426 be]] replaced by an autoresponse message or alias pointing people to 1427 the new list and procedures. That new list is, as specified above, 1428 urn@ietf.org. 1430 8. Security and Privacy Considerations 1432 The definition of a URN namespace needs to account for potential 1433 security and privacy issues related to assignment, use, and 1434 resolution of names within the URN namespace (e.g., some URN 1435 resolvers might assign special meaning to certain characters in the 1436 NSS); see Section 6.4.4 for further discussion. 1438 In most cases, URN namespaces provide a way to declare public 1439 information. Normally, these declarations will have a relatively low 1440 security profile, however there is always the danger of "spoofing" 1441 and providing misinformation. Information in these declarations 1442 ought to be taken as advisory. 1444 9. References 1446 9.1. Normative References 1448 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 1449 October 1969. 1451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1452 Requirement Levels", BCP 14, RFC 2119, March 1997. 1454 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1455 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1456 3986, January 2005. 1458 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1459 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1460 May 2008. 1462 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1463 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1465 9.2. Informative References 1467 [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The 1468 "doi" URI Scheme for the Digital Object Identifier (DOI)", 1469 June 2003, 1470 . 1472 [I-D.saintandre-iana-urn] 1473 Saint-Andre, P. and M. Cotton, "A Uniform Resource Name 1474 (URN) Namespace for IANA Registries", draft-saintandre- 1475 iana-urn-01 (work in progress), February 2013. 1477 [ISO.27729.2012] 1478 Technical Committee ISO/TC 46, Information and 1479 documentation, Subcommittee SC 9, Identification and 1480 description., "Information and documentation - 1481 International standard name identifier (ISNI)", ISO Draft 1482 Standard 27729, 03 2012. 1484 [ISO.3166-1] 1485 ISO, "Codes for the representation of names of countries 1486 and their subdivisions -- Part 1: Country codes", ISO 1487 3166-1:2013, 2013. 1489 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1490 Uniform Resource Names", RFC 1737, December 1994. 1492 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1493 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 1494 December 1994, . 1496 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1497 1808, DOI 10.17487/RFC1808, June 1995, 1498 . 1500 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1502 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1503 Name Resolution", RFC 2276, January 1998. 1505 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1506 Necessary for URN Resolution", RFC 2483, January 1999. 1508 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1509 DOI 10.17487/RFC2648, August 1999, 1510 . 1512 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1513 Standard Number) as URN (Uniform Resource Names) within an 1514 ISSN-URN Namespace", RFC 3044, January 2001. 1516 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1517 Book Numbers as Uniform Resource Names", RFC 3187, October 1518 2001. 1520 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 1521 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 1522 October 2001, . 1524 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1525 "Uniform Resource Names (URN) Namespace Definition 1526 Mechanisms", BCP 66, RFC 3406, October 2002. 1528 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1529 Text on Security Considerations", BCP 72, RFC 3552, July 1530 2003. 1532 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1533 for Extensions to the Extensible Messaging and Presence 1534 Protocol (XMPP)", RFC 4854, April 2007. 1536 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1537 (IRIs) and Uniform Resource Identifiers (URIs) for the 1538 Extensible Messaging and Presence Protocol (XMPP)", RFC 1539 5122, February 2008. 1541 [RFC5890] Klensin, J., "Internationalized Domain Names for 1542 Applications (IDNA): Definitions and Document Framework", 1543 RFC 5890, August 2010. 1545 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1546 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1547 March 2011, . 1549 [RFC6288] Reed, C., "URN Namespace for the Defence Geospatial 1550 Information Working Group (DGIWG)", RFC 6288, DOI 10.17487 1551 /RFC6288, August 2011, 1552 . 1554 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1555 "Deprecating the "X-" Prefix and Similar Constructs in 1556 Application Protocols", BCP 178, RFC 6648, June 2012. 1558 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1559 Specifications and Registration Procedures", BCP 13, RFC 1560 6838, January 2013. 1562 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1563 Purposes", RFC 6943, May 2013. 1565 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1566 for Examples", BCP 183, RFC 6963, May 2013. 1568 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1569 Morris, J., Hansen, M., and R. Smith, "Privacy 1570 Considerations for Internet Protocols", RFC 6973, July 1571 2013. 1573 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 1574 Gosden, "A Uniform Resource Name Namespace for the Global 1575 System for Mobile Communications Association (GSMA) and 1576 the International Mobile station Equipment Identity 1577 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, 1578 . 1580 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 1581 7282, June 2014. 1583 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1584 7320, July 2014. 1586 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 1587 P. Kyzivat, "URNs for the Alert-Info Header Field of the 1588 Session Initiation Protocol (SIP)", RFC 7462, DOI 10.17487 1589 /RFC7462, March 2015, 1590 . 1592 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1593 Enforcement, and Comparison of Internationalized Strings 1594 Representing Usernames and Passwords", RFC 7613, DOI 1595 10.17487/RFC7613, August 2015, 1596 . 1598 [UAX31] The Unicode Consortium, "Unicode Standard Annex #31: 1599 Unicode Identifier and Pattern Syntax", June 2015, 1600 . 1602 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015, 1603 . 1605 [URI-Registry] 1606 IANA, "Permanent URI Schemes", . 1609 [XML-BASE] 1610 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1611 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1612 January 2009, 1613 . 1615 [XML-NAMES] 1616 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1617 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1618 Web Consortium Recommendation REC-xml-names-20091208, 1619 December 2009, 1620 . 1622 Appendix A. Registration Template 1624 Namespace ID: Requested of IANA (formal) or assigned by IANA 1625 (informal). 1627 Version: The version of the registration, starting with 1 and 1628 incrementing by 1 with each new version. 1630 Date: The date when the registration is requested of IANA, using the 1631 format YYYY-MM-DD. 1633 Registrant: The person or organization that has registered the NID, 1634 including the name and address of the registering organization, as 1635 well as the name and contact information (email, phone number, or 1636 postal address) of the designated contact person. If the 1637 registrant is a recognized standards development organization, 1638 scientific society, or similar body requesting the fast track 1639 registration procedure (see Section 6.3), that information should 1640 be clearly indicated in this section of the template. 1642 Purpose: Described under Section 6.4.1 of this document. 1644 Syntax: Described under Section 6.4.2 of this document. Unless the 1645 registration explicitly describes the semantics of r-components, 1646 q-components, and f-components in the context of this URN 1647 namespace, those semantics are undefined. 1649 Assignment: Described under Section 6.4.3 of this document. 1651 Security and Privacy: Described under Section 6.4.4 of this 1652 document. 1654 Interoperability: Described under Section 6.4.5 of this document. 1656 Resolution: Described under Section 6.4.6 of this document. 1658 Documentation: A pointer to an RFC, a specification published by 1659 another standards development organization, or another stable 1660 document that provides further information about this URN 1661 namespace. 1663 Additional Information: Described under Section 6.4.7 of this 1664 document. 1666 Revision Information: Description of changes from prior version(s). 1667 (Applicable only when earlier registrations have been revised.) 1669 Appendix B. Changes from RFC 2141 1671 This document makes substantive changes from the syntax and semantics 1672 of [RFC2141]: 1674 B.1. Syntax changes from RFC 2141 1676 The syntax of URNs as provided in [RFC2141] was defined before the 1677 updated specification of URIs in [RFC3986]. The definition of URN 1678 syntax is updated in this document to do the following: 1680 o Ensure consistency with the URI syntax. 1682 o Facilitate the use of URNs with parameters similar to URI queries 1683 and fragments. 1685 o Permit parameters influencing URN resolution. 1687 o Ease the use of URNs with non-URN identifier systems that include 1688 the '/' character. 1690 In particular, this specification does the following: 1692 o Extends URN syntax to explicitly allow the characters '/', "?", 1693 and "#", which were reserved for future use by RFC 2141. This 1694 change effectively also allows several components of the URI 1695 syntax although without necessarily tying those components to URI 1696 semantics. 1698 o Defines general syntax for an additional component that can be 1699 used in interactions with a URN resolution service. 1701 o Disallows "-" at the end of a NID. 1703 o Allows the "/", "~", and "&" characters in the namespace-specific 1704 string (NSS). 1706 o Makes several smaller syntax adjustments. 1708 B.2. Other changes from RFC 2141 1710 o Formally registers 'urn' as a URI scheme. 1712 o Allows what are now called r-components, q-components, and 1713 f-components. 1715 In addition, some of the text has been updated to be consistent with 1716 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1717 the processes for registering information with the IANA [RFC5226], as 1718 well as more modern guidance with regard to security [RFC3552], 1719 privacy [RFC6973], and identifier comparison [RFC6943]. 1721 Appendix C. Changes from RFC 3406 1723 This document makes the following substantive changes from [RFC3406]: 1725 1. Relaxes the registration policy for formal URN namespaces from 1726 "IETF Review" to "Expert Review" as discussed in Section 6.2. 1728 2. Removes the category of experimental URN namespaces, consistent 1729 with [RFC6648]. Experimental URN namespaces were denoted by 1730 prefixing the namespace identifier with the string "X-". Because 1731 experimental URN namespaces were never registered, removing the 1732 experimental category has no impact on the existing registries. 1733 Because experimental URN namespaces are not managed, strings 1734 conforming to URN syntax within experimental URN namespaces are 1735 not valid URNs. Truly experimental usages may, of course, employ 1736 the 'example' namespace [RFC6963]. 1738 3. Adds some information to, but generally simplifies, the URN 1739 namespace registration template. 1741 Appendix D. Contributors 1743 RFC 2141, which provided the basis for the syntax portion of this 1744 document, was authored by Ryan Moats. 1746 RFC 3406, which provided the basis for the namespace portion of this 1747 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1748 Renato Iannella, and Patrik Faltstrom. 1750 Their work is gratefully acknowledged. 1752 Appendix E. Acknowledgements 1754 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1755 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1756 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1757 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1758 participants in the URNBIS WG for their input. Alfred Hoenes in 1759 particular edited an earlier version of this document and served as 1760 co-chair of the URNBIS WG. 1762 Juha Hakala deserves special recognition for his dedication to 1763 successfully completing this work, as do Andrew Newton and Melinda 1764 Shore in their roles as working group co-chairs and Barry Leiba in 1765 his role as area director and then as co-chair. 1767 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1769 [[RFC Editor: please remove this appendix before publication.]] 1771 F.1. Changes from -08 to -09 1773 o Altered the text in Section 4 to reflect list discussions about 1774 the earlier phrasing. Also added DOI example and citation to that 1775 section. 1777 o Clarified the naming rules for formal namespaces and their 1778 relationship to ISO 3166, IDNA, etc., reserved strings. 1780 o Added an explicit statement about use of URNs in various protocols 1781 and contexts to Section 4. 1783 o Clarified that experimental namespace NIDs, which were explicitly 1784 not registered, are not valid URNs (in Section 5. 1786 o Transformed the partial production in Section 5.2 into valid ABNF. 1788 o Added more text about p-/q-/f-components and recommendations about 1789 use. 1791 o Added clarifying note about "?" within q-components and 1792 f-components. 1794 o Added explicit requirement that revisions of existing 1795 registrations document the changes and added a slot for that 1796 description to the template. 1798 o Many small editorial changes and adjustments including adding 1799 additional references and cross-references for clarification. 1801 o Inserted a placeholder for additional examples. 1803 F.2. Changes from -09 to -10 1805 o Several clarifying editorial changes, most suggested by Ted Hardie 1806 and Henry S. Thompson (some of them off-list). 1808 o Added a large number of placeholders that identify issues that 1809 require WG consideration and resolution (or WG delegation to the 1810 editors). 1812 F.3. Changes from -10 to -11 1814 o Removed most of the placeholders added in -10. Supplied new text 1815 as required or suggested by on-list discussion of those issues. 1817 o Replaced the conformance examples Section 3.2 with a more complete 1818 collection and discussion. 1820 o Revised and consolidated the registration procedure, and added 1821 provisions for NIDs that are the subject of standards and for 1822 avoiding race conditions about NID strings. 1824 o In response to independent comments from Ted Hardie and Henry S. 1825 Thompson, called attention to the possibility of conflicts between 1826 NID strings and various claims of national, corporate, and other 1827 perogatives. 1829 o Changed the production for assigned-name as suggested by Lars 1830 Svensson. 1832 o Several clarifying editorial changes including correcting a glitch 1833 in instructions to the RFC Editor. 1835 F.4. Changes from -11 to -12 1837 o Removed p-components as a standalone construct, and instead folded 1838 them into the NSS. 1840 o Defined syntax for r-components as a way to pass information to 1841 resolvers, but left the semantics for future standardization 1842 efforts. 1844 o Further tuned the discussion of interoperability and related 1845 registration issues. 1847 o Made a number of editorial corrections and reorganized the syntax 1848 material in Section 2 somewhat to make it internally consistent 1849 and keep the relationship to RFC 3986 clear. 1851 F.5. Changes from -12 to -13 1853 o More precisely defined the semantics of the optional components. 1855 o Defined the term "resolution" and clarified several related 1856 matters throughout the text. 1858 o Clarified terminological relationship to RFC 3986. 1860 o Further cleansed the document of p-components. 1862 o Corrected several examples to avoid confusion with existing 1863 identifier systems. 1865 o Improved text regarding the purpose of namespaces being 1866 registered. 1868 F.6. Changes from -13 to -14 1870 o Reverted the ABNF to what had been defined in version -12. 1872 o Added fast-track approval process for standards-related 1873 organizations, scientific societies, and similar bodies (similar 1874 to RFC 6838 for Media Types). 1876 F.7. Changes from -14 to -15 1878 o Reorganized the Introduction slightly, adding new subsection 1.1 1879 and making Terminology (the former Section 2) Section 1.2. 1881 o Tightened the discussion of "resolution" somewhat to try to 1882 mitigate some on-list confusion. 1884 o Added some text about character set choices and repertoires 1885 (consistent with the Section 1.1 explanation). 1887 o Moved away from "?" and "??" for q-component and r-component 1888 delimiters and went to two-character sequences for each. This 1889 includes several changes to the text to remove or modify 1890 discussions of string termination and the role of a question mark 1891 not followed by one of the new delimiters. 1893 o Redefined r-component to be an ASCII resolver ID and a string. 1894 Neither is further defined in this specification and text has been 1895 added to say that. 1897 o Several editorial changes to improve clarity, most following up on 1898 comments made on the list. These included modifying the table of 1899 contents so that the subsections on optional components now appear 1900 there. 1902 F.8. Changes from -15 (2016-02-04) to -16 1904 o Rewrote the introductory material to make the relationship to 1905 other specifications more clear and allow removing or altering 1906 text that was stated in terms of changes from 2141. The 1907 specification is now self-contained with regard to the earlier 1908 definitions and descriptions of URNs. 1910 o Removed the parts of Section 2 that were really a description of 1911 changes from RFC 2141 to Appendix B, where such changes are 1912 enumerated. Similarly, removed most material describing changes 1913 from RFC 3406 to Appendix C. 1915 o Replaced one example. 1917 o Rearranged and rewrote text to improve clarity and relationships 1918 to other documents and to reduce redundant material. 1920 o Made it more clear that r-components, despite the partial syntax 1921 specification, are reserved for future standardization. 1923 o Clarified that there can be URNs that do not resolve to URLs. 1925 o Added pointers to make it clear that the Syntax material in 1926 Section 2 is not self-contained, e.g., that its subsections and 1927 other sections further restrict strings that can be used for NIDs 1928 and so on. 1930 o Added an "Additional Information" section to the registration 1931 template. See list discussion on and about 2016-03-18. 1933 o Minor editorial/ typographic fixes (per comment from Lars). 1935 F.9. Changes from -16 (2016-04-16) to -17 1937 o Clarified material about copying q-components, including adding an 1938 example. 1940 o Modified the document in several places to try to respond to 1941 concerns about the unqualified use of the term "equivalence". The 1942 term has been eliminated in one or two places and changed to "URN- 1943 equivalence" in situations in which the scheme is known and URN- 1944 specific rules are being applied. 1946 o Editorial and typographic fixes. 1948 o Temporarily (this version only) added [[CREF...]] placeholders to 1949 identify outstanding issues that might usefully be discussed 1950 during the 2016-06-29 virtual meeting but that must be resolved in 1951 some way for the document to move forward. 1953 F.10. Changes from -17 (2016-06-27) to -18 1955 o Removed "cref placeholders" inserted for -17 and the 2016-06-29 1956 virtual meeting. 1958 o Per interim meeting 2016-06-29, changed "equivalent" and 1959 "equivalence" to "URN-equivalent" and "URN-equivalence" in a 1960 number of locations. 1962 o Per interim meeting 2016-06-29 and previous list discussion, 1963 clarified the usage of the terms 'name', 'namespace', 'URN 1964 namespace', 'identifier system', 'URN', and 'NSS'. 1966 o Per interim meeting 2016-06-29, changed syntax so that r-component 1967 precedes q-component. 1969 F.11. Changes from -18 (2016-09-05) to -19 1971 o Small editorial changes to improve clarity. 1973 o Added cross-references to material, especially in Section 6 and as 1974 derived from RFC 3406. 1976 o Replaced material on relative references to reflect the on-list 1977 discussions in August and September and generally to say less here 1978 and leave more to RFC 3986. 1980 o Expanded the discussion of resolution, dereferencing, 1981 representations, metadata, and intended uses for URNs. 1983 o Removed the term "abstract designator". 1985 o Replaced the term "URL" in most instances with the term "locator" 1986 or the phrase "URI that is a locator". 1988 o Rearranged and partially rewrote the "Terminology" section to 1989 reflect the above change to "URL" usage, reflect the actual use of 1990 the term "URN" in the document, and be clear about the meaning (or 1991 lack thereof) of "name". 1993 F.12. Changes from -19 (2016-12-31) to -20 1995 o After getting permission from Ryan Moats, author of RFC 2141, 1996 changed the IPR status to reflect current preferred rights. 1998 o Added text to clarify the role of ":" inside the NSS. 2000 o Removed the reference to the semantics clarification I-D from the 2001 draft, as discussed on the mailing list. 2003 o Corrected two remaining instances of "3896" rather than "3986". 2005 F.13. Changes from -20 (2017-02-02) to -21 2007 o Added a new subsection to IANA Considerations to note the change 2008 in mailing list for NID registration requests. 2010 o Eliminated "Basic Latin Repertoire" statement in favor of "outside 2011 the ASCII range" as used elsewhere in the document. 2013 o Minor editorial improvements and corrections. 2015 F.14. Changes from -21 (2017-02-27) to -22 2017 o IESG-requested changes to conditions for use of r-components and 2018 apparent normative language in the template. 2020 o IESG-requested changes to make the relevance of privacy 2021 considerations in namespace definitions more clear and to add a 2022 reference to RFC 7254 as a useful example. 2024 Authors' Addresses 2026 Peter Saint-Andre 2027 Filament 2028 P.O. Box 787 2029 Parker, CO 80134 2030 USA 2032 Email: peter@filament.com 2033 URI: https://filament.com/ 2034 John C Klensin 2035 1770 Massachusetts Ave, Ste 322 2036 Cambridge, MA 02140 2037 USA 2039 Phone: +1 617 245 1457 2040 Email: john-ietf@jck.com