idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-20.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 (February 2, 2017) is 2637 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 February 2, 2017 6 Expires: August 6, 2017 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-20 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 August 6, 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 . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 29 99 7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 29 100 7.2. Registration of URN Namespaces . . . . . . . . . . . . . 30 101 8. Security and Privacy Considerations . . . . . . . . . . . . . 30 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 104 9.2. Informative References . . . . . . . . . . . . . . . . . 31 105 Appendix A. Registration Template . . . . . . . . . . . . . . . 34 106 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 35 107 B.1. Syntax changes from RFC 2141 . . . . . . . . . . . . . . 35 108 B.2. Other changes from RFC 2141 . . . . . . . . . . . . . . . 36 109 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 36 110 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 37 111 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 37 112 Appendix F. Change log for versions of draft-ietf-urnbis- 113 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 37 114 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 37 115 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 38 116 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 38 117 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 39 118 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 39 119 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 39 120 F.7. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 40 121 F.8. Changes from -15 (2016-02-04) to -16 . . . . . . . . . . 40 122 F.9. Changes from -16 (2016-04-16) to -17 . . . . . . . . . . 41 123 F.10. Changes from -17 (2016-06-27) to -18 . . . . . . . . . . 41 124 F.11. Changes from -18 (2016-09-05) to -19 . . . . . . . . . . 42 125 F.12. Changes from -19 (2016-12-31) to -20 . . . . . . . . . . 42 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 128 1. Introduction 130 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 131 [RFC3986] that is assigned under the "urn" URI scheme and a 132 particular URN namespace, with the intent that the URN will be a 133 persistent, location-independent resource identifier. A URN 134 namespace is a collection of such URNs, each of which is (1) unique, 135 (2) assigned in a consistent and managed way, and (3) assigned 136 according to a common definition. (Some URN namespaces create names 137 that exist only as URNs, whereas others assign URNs based on names 138 that were already created in non-URN identifier systems, such as 139 ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].) 141 The assignment of URNs is done by an organization (or, in some cases, 142 according to an algorithm or other automated process) that has been 143 formally delegated a URN namespace within the "urn" scheme (e.g., a 144 URN in the 'example' URN namespace [RFC6963] might be of the form 145 "urn:example:foo"). 147 This document rests on two key assumptions: 149 1. Assignment of a URN is a managed process. 151 2. The space of URN namespaces is itself managed. 153 While other URI schemes may allow resource identifiers to be freely 154 chosen and assigned, such is not the case for URNs. The syntactical 155 correctness of a name starting with "urn:" is not sufficient to make 156 it a URN. In order for the name to be a valid URN, the namespace 157 identifier (NID) needs to be registered in accordance with the rules 158 defined here and the remaining parts of the assigned-name portion of 159 the URN need to be generated in accordance with the rules for the 160 registered URN namespace. 162 So that information about both URN syntax and URN namespaces is 163 available in one place, this document does the following: 165 1. Defines the canonical syntax for URNs in general (in a way that 166 is consistent with URI syntax), specifies methods for determining 167 URN-equivalence, and discusses URI conformance. 169 2. Specifies a method for defining a URN namespace and associating 170 it with a namespace identifier (NID), and describes procedures 171 for registering URN NIDs with the Internet Assigned Numbers 172 Authority (IANA). 174 For URN syntax and URN namespaces, this document modernizes and 175 replaces the original specifications for URN syntax [RFC2141] and for 176 the definition and registration of URN namespaces [RFC3406]. These 177 modifications build on the key requirements provided in the original 178 functional description for URNs [RFC1737] and on the lessons of many 179 years of experience. In those original documents and in the present 180 one, the intent is to define URNs in a consistent manner so that, 181 wherever practical, the parsing, handling, and resolution of URNs can 182 be independent of the URN namespace within which a given URN is 183 assigned. 185 Together with input from several key user communities, the history 186 and experiences with URNs dictated expansion of the URN definition to 187 support new functionality, including the use of syntax explicitly 188 reserved for future standardization in RFC 2141. All URN namespaces 189 and URNs that were valid under the earlier specifications remain 190 valid even though it may be useful to update some of them to take 191 advantage of new features. 193 The foregoing considerations, together with various differences 194 between URNs and URIs that are locators (specifically URLs) as well 195 as the greater focus on URLs in RFC 3986 as the ultimate successor to 196 [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 197 and this specification that appear (or perhaps actually are) not 198 completely consistent, especially with regard to actions or semantics 199 other than the basic syntax itself. If such situations arise, 200 discussions of URNs and URN namespaces should be interpreted 201 according to this document and not by extrapolation from RFC 3986. 203 Summaries of changes from RFC 2141 and RFC 3406 appear in Appendix B 204 and Appendix C respectively. This document obsoletes both [RFC2141] 205 and [RFC3406]. While it does not explicitly update or replace 206 [RFC1737] or [RFC2276], the reader who references those documents 207 should be aware that the conceptual model of URNs in this document is 208 slightly different from those older specifications. 210 1.1. Terminology 212 The following terms are distinguished from each other as described 213 below: 215 URN: A URI (as defined in RFC 3986) using the "urn" scheme and with 216 the properties of a "name" as described in that document as well 217 as the properties described in this one. The term applies to the 218 entire URI including its optional components. Note to the reader: 219 the term "URN" has been used in other contexts to refer to a URN 220 namespace, the namespace identifier (NID), the Assigned-name, and 221 to URIs that do not use the "urn" scheme. All but the last of 222 these is described using more specific terminology elsewhere in 223 this document, but, because of those other uses, the term should 224 be used and interpreted with care. 226 Locator: An identifier that provides a means of accessing a 227 resource. 229 Identifier system: A managed collection of names. This document 230 refers to identifier systems outside the context of URNs as "non- 231 URN identifier systems". 233 URN namespace: An identifier system that is associated with a URN 234 namespace identifier (NID). 236 NID: The identifier associated with a URN namespace. 238 NSS: The URN-namespace-specific part of a URN. 240 Assigned-name: The combination of the 'urn:' scheme, the NID, and 241 the NSS. An "Assigned-name" is consequently a substring of a URN 242 (as defined above) if that URN contains any additional components 243 (see Section 2). 245 The term "name" is deliberately not defined here and should be (and 246 in practice, is) used only very informally. RFC 3986 uses the term 247 as a category of URI distinguished from "locator" (Section 1.1.3) but 248 also uses it in other contexts. If those uses are treated as 249 definitions, they conflict with, e.g., the idea of the name of a URN 250 namespace, i.e., a NID or terms associated with non-URN identifier 251 systems. 253 This document uses the terms "resource", "identifier", "identify", 254 "dereference", "representation", and "metadata" roughly as defined in 255 the URI specification [RFC3986]. 257 This document uses the terms "resolution" and "resolver" in roughly 258 the sense in which they were used in the original discussion of 259 architectural principles for URNs [RFC2276], i.e., "resolution" is 260 the act of supplying services related to the identified resource, 261 such as translating the persistent URN into one or more current 262 locators for the resource, delivering metadata about the resource in 263 an appropriate format, or even delivering a representation of the 264 resource (e.g., a document) without requiring further intermediaries. 265 At the time of this writing, resolution services are described in 266 [RFC2483]. 268 On the distinction between representations and metadata, see 269 Section 1.2.2 of [RFC3986]. 271 Several other terms related to "normalization" operations that are 272 not part of the Unicode Standard [UNICODE] are also used here as they 273 are in RFC 3986. 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 277 "OPTIONAL" in this document are to be interpreted as described in 278 [RFC2119]. 280 1.2. Design Tradeoffs 282 To a degree much greater than when URNs were first considered and 283 their uses outlined (see [RFC1737]), issues of persistent identifiers 284 on the Internet involve fundamental design tradeoffs that are much 285 broader than URNs or the URN approach, and even touch on open 286 research questions within the information sciences community. Ideal 287 and comprehensive specifications about what should be done or 288 required across the entire universe of URNs would require general 289 agreement about, and solutions to, a wide range of such issues. 290 Although some of those issues were introduced by the Internet or 291 computer-age approaches to character encodings and data abstraction, 292 others predate the Internet and computer systems by centuries; there 293 is unlikely to be agreement about comprehensive solutions in the near 294 future. 296 Although this specification consequently contains some requirements 297 and flexibility that would not be present in a more perfect world, 298 this has been necessary in order to produce a consensus specification 299 that provides a modernized definition of URNs (the unattractive 300 alternative would have been to not modernize the definition in spite 301 of widespread deployment). 303 The following sub-sections describe two of the relevant issues in 304 greater detail. 306 1.2.1. Resolution 308 One issue that is specific to URNs (as opposed to naming systems in 309 general) is the fairly difficult topic of "resolution", discussed in 310 Section 1.1, Section 2.3.1, Section 6.4.6, and elsewhere below. 312 With traditional Uniform Resource Locators (URLs), i.e., with most 313 URIs that are locators, resolution is relatively straightforward 314 because it is used to determine an access mechanism which in turn is 315 used to dereference the locator by (typically) retrieving a 316 representation of the associated resource, such as a document (see 317 Section 1.2.2 of [RFC3986]). 319 By contrast, resolution for URNs is more flexible and varied. 321 One important case involves the mapping of a URN to one or more 322 locators. In this case, the end result is still a matter of 323 dereferencing the mapped locator(s) to one or more representations. 324 The primary difference here is persistence: even if a mapped locator 325 has changed (e.g., a DNS domain name has changed hands and a URL has 326 not been modified to point to a new location or, in a more extreme 327 and hypothetical case, the DNS is replaced entirely), a URN user will 328 be able to obtain the correct representation (e.g., a document) as 329 long as the resolver has kept its URN-to-locator mappings up to date. 330 Consequently, the relevant relationships can be defined quite 331 precisely for URNs that resolve to locators which in turn are 332 dereferenced to a representation. 334 However, this specification permits several other cases of URN 335 resolution as well as URNs for resources that do not involve 336 information retrieval systems. This is true either individually for 337 particular URNs or (as defined below) collectively for entire URN 338 namespaces. 340 Consider a namespace of URNs that resolve to locators which in turn 341 are dereferenced only to metadata about resources because the 342 underlying systems contain no representations of those resources; an 343 example might be a URN namespace for International Standard Name 344 Identifiers (ISNI) as that identifier system is defined in 345 [ISO.27729.2012], wherein by default a URN would be resolved only to 346 a metadata record describing the individual identified by the ISNI. 348 Consider also URNs that resolve to representations only if the 349 requesting entity is authorized to obtain the representation, whereas 350 other entities can obtain only metadata about the resource; an 351 example might be documents held within the legal depository 352 collection of a national library. 354 Finally, some URNs might not be intended to resolve to locators at 355 all; examples might include URNs identifying XML namespace names 356 (e.g., the 'dgiwg' URN namespace specified by [RFC6288]), URNs 357 identifying application features that can be supported within a 358 communications protocol (e.g., the 'alert' URN namespace specified by 359 [RFC7462]), and URNs identifying enumerated types such as values in a 360 registry (e.g., a URN namespace could be used to individually 361 identify the values in all IANA registries, as provisionally proposed 362 in [I-D.saintandre-iana-urn]). 364 Various types of URNs and multiple resolution services which may be 365 available for them leave the concept of "resolution" more complicated 366 but also much richer for URNs than the straightforward case of 367 resolution to a locator that is dereferenced to a representation. 369 1.2.2. Character Sets and Encodings 371 A similar set of considations apply to character sets and encodings. 372 URNs, especially URNs that will be used as user-facing identifiers, 373 should be convenient to use in local languages and writing systems, 374 easily specified with a wide range of keyboards and local 375 conventions, and unambiguous. There are tradeoffs among those goals 376 and it is impossible at present to see how a simple and readily- 377 understandable set of rules could be developed that would be optimal, 378 or even reasonable, for all URNs. The discussion in Section 2.2 379 defines an overall framework that should make generalized parsing and 380 processing possible, but also makes recommendations about rules for 381 individual URN namespaces. 383 2. URN Syntax 385 As discussed above, the syntax for URNs in this specification allows 386 significantly more functionality than was the case in the earlier 387 specifications, most recently [RFC2141]. It is also harmonized with 388 the general URI syntax [RFC3986] (which, it must be noted, was 389 completed after the earlier URN specifications). 391 However, this specification does not extend the URN syntax to allow 392 direct use of characters outside the ASCII range [RFC20]. That 393 restriction implies that any such characters need to be percent- 394 encoded as described in Section 2.1 of the URI specification 395 [RFC3986]. 397 The basic syntax for a URN is defined using the Augmented Backus-Naur 398 Form (ABNF) as specified in [RFC5234]. Rules not defined here 399 (specifically: alphanum, fragment, and pchar) are defined as part of 400 the URI syntax [RFC3986] and used here to point out the syntactic 401 relationship with the terms used there. The definitions of some of 402 the terms used below are not comprehensive; additional restrictions 403 are imposed by the prose that can be found in sections of this 404 document that are specific to those terms (especially r-component in 405 Section 2.3.1 and q-component in Section 2.3.2). 407 namestring = assigned-name 408 [ rq-components ] 409 [ "#" f-component ] 410 assigned-name = "urn" ":" NID ":" NSS 411 NID = (alphanum) 0*30(ldh) (alphanum) 412 ldh = alphanum / "-" 413 NSS = pchar *(pchar / "/") 414 rq-components = [ "?+" r-component ] 415 [ "?=" q-component ] 416 r-component = pchar *( pchar / "/" / "?" ) 417 q-component = pchar *( pchar / "/" / "?" ) 418 f-component = fragment 420 The question mark character "?" can be used without percent-encoding 421 inside r-components, q-components, and f-components. Other than 422 inside those components a "?" that is not immediately followed by "=" 423 or "+" is not defined for URNs and SHOULD be treated as a syntax 424 error by URN-specific parsers and other processors. 426 The following sections provide additional information about the 427 syntactic elements of URNs. 429 2.1. Namespace Identifier (NID) 431 Namespace identifiers (NIDs) are case insensitive (e.g., "ISBN" and 432 "isbn" are equivalent). 434 Characters outside the ASCII range [RFC20] are not permitted in NIDs, 435 and no encoding mechanism for such characters is supported. 437 Section 5.1 and Section 5.2 impose additional constraints on the 438 strings that can be used as NIDs, i.e., the syntax shown above is not 439 comprehensive. 441 2.2. Namespace Specific String (NSS) 443 The namespace specific string (NSS) is a string, unique within a URN 444 namespace, that is assigned and managed in a consistent way and that 445 conforms to the definition of the relevant URN namespace. The 446 combination of the NID (unique across the entire "urn" scheme) and 447 the NSS (unique within the URN namespace) ensures that the resulting 448 URN is globally unique. 450 The NSS as specified in this document allows several characters not 451 permitted by earlier specifications (see Appendix B). In particular, 452 the "/" character, which is now allowed, effectively makes it 453 possible to encapsulate hierarchical names from non-URN identifier 454 systems. For instance, consider the hypothetical example of a 455 hierarchical identifier system in which the names take the form of a 456 sequence of numbers separated by the "/" character, such as 457 "1/406/47452/2". If the authority for such names were to use URNs, 458 it would be natural to place the existing name in the NSS, resulting 459 in URNs such as "urn:example:1/406/47452/2". 461 Those changes to the syntax for the NSS do not modify the encoding 462 rules for URN namespaces that were defined in accordance with 463 [RFC2141]. If any such URN namespace whose names are used outside of 464 the URN context (i.e., in a non-URN identifier system) also allows 465 the use of "/", "~", or "&" in the native form within that identifier 466 system, then the encoding rules for that URN namespace are not 467 changed by this specification. 469 Depending on the rules governing a non-URN identifier system and its 470 associated URN namespace, names that are valid in that identifier 471 system might contain characters that are not allowed by the "pchar" 472 production referenced above (e.g., characters outside the ASCII range 473 or, consistent with the restrictions in RFC 3986, the characters "/", 474 "?", "#", "[", and "]"). While such a name might be valid within the 475 non-URN identifier system, it is not a valid URN until it has been 476 translated into an NSS that conforms to the rules of that particular 477 URN namespace. In the case of URNs that are formed from names that 478 exist separately in a non-URN identifier system, translation of a 479 name from its "native" format to URN format is accomplished by using 480 the canonicalization and encoding methods defined for URNs in general 481 or specific rules for that URN namespace. Software that is not aware 482 of namespace-specific canonicalization and encoding rules MUST NOT 483 construct URNs from the name in the non-URN identifier system. 485 In particular, with regard to characters outside the ASCII range, 486 URNs that appear in protocols or that are passed between systems MUST 487 use only Unicode characters encoded in UTF-8 and further encoded as 488 required by RFC 3986. To the extent feasible consistent with the 489 requirements of names defined and standardized elsewhere, as well as 490 the principles discussed in Section 1.2, the characters used to 491 represent names SHOULD be restricted to either ASCII letters and 492 digits or to the characters and syntax of some widely-used model such 493 as those of IDNA [RFC5890], PRECIS [RFC7613], or the Unicode 494 Identifier and Pattern Syntax specification [UAX31]. 496 In order to make URNs as stable and persistent as possible when 497 protocols evolve and the environment around them changes, URN 498 namespaces SHOULD NOT allow characters outside the basic Latin 499 repertoire [RFC20] unless the nature of the particular URN namespace 500 makes such characters necessary. 502 2.3. Optional Components 504 This specification includes three optional components in the URN 505 syntax. They are known as r-component, q-component, and f-component 506 and are described in more detail below. Because this specification 507 focuses almost exclusively on URN syntax, it does not define detailed 508 semantics of these components for URNs in general. However, each of 509 these components has a distinct role that is independent of any given 510 URN and its URN namespace. It is intended that clients will be able 511 to handle these components uniformly for all URNs. These components 512 MAY be used with URNs from existing URN namespaces, whether or not a 513 URN namespace explicitly supports them. However, consistent with the 514 approach taken in RFC 3986, the behavior of a URN that contains 515 components that are undefined or meaningless for a particular URN 516 namespace or resource is not defined. The following sections 517 describe these optional components and their interpretation in 518 greater detail. 520 2.3.1. r-component 522 The r-component is intended for passing parameters to URN resolution 523 services (taken broadly, see Section 1.2) and interpreted by those 524 services. (By contrast, passing parameters to the resources 525 identified by a URN, or to applications that manage such resources, 526 is handled by q-components as described in the next section.) 528 The URN r-component has no syntactic counterpart in any other known 529 URI scheme. 531 The sequence "?+" introduces the r-component. The r-component ends 532 with a "?=" sequence (which begins a q-component) or a "#" character 533 (number sign, which begins an f-component). If neither of those 534 appear, the r-component continues to the end of the URN. Note that 535 characters outside the ASCII range [RFC20] MUST be percent-encoded 536 using the method defined in Section 2.1 of the generic URI 537 specification [RFC3986]. 539 As described under Section 3, the r-component SHALL NOT be taken into 540 account when determining URN-equivalence. However, the r-component 541 SHALL be supplied along with the URN when presenting a request to a 542 URN resolution service. 544 This document defines only the syntax of the r-component and reserves 545 it for future use. The exact semantics of the r-component and its 546 use in URN resolution protocols are a matter for potential 547 standardization in separate specifications, presumably including 548 specifications that define conventions and a registry for resolution 549 service identifiers. 551 Consider the hypothetical example of passing parameters to a 552 resolution service (say, an ISO alpha-2 country code [ISO.3166-1] in 553 order to select the preferred country in which to search for a 554 physical copy of a book). This could perhaps be accomplished by 555 specifying the country code in the r-component, resulting in URNs 556 such as: 558 urn:example:foo-bar-baz-qux?+CCResolve:cc=uk 560 While the above should serve as a general explanation and 561 illustration of the intent for r-components, there are many open 562 issues with them, including their relationship to resolution 563 mechanisms associated with the particular URN namespace at 564 registration time. Thus r-components SHOULD NOT be used for actual 565 URNs until additional development and standardization work is 566 complete, including specification of any necessary registration 567 mechanisms. 569 2.3.2. q-component 571 The q-component is intended for passing parameters to either the 572 named resource or a system that can supply the requested service, for 573 interpretation by that resource or system. (By contrast, passing 574 parameters to URN resolution services is handled by r-components as 575 described in the previous section.) 577 The URN q-component has the same syntax as the URI query component, 578 but is introduced by "?=", not "?" alone. For a URN that may be 579 resolved to a URI that is a locator, the semantics of the q-component 580 are identical to those for the query component of that URI. Thus URN 581 resolvers returning a URI that is a locator for a URN with a 582 q-component do this by copying the q-component from the URN to the 583 query component of the URI. An example of the copying operation 584 appears below. 586 This specification does not specify a required behavior in the case 587 of URN resolution to a URI that is a locator when the original URN 588 has a q-component and the URI has a query string. Different 589 circumstance may require different approaches. Resolvers SHOULD 590 document their strategy in such cases. 592 If the URN does not resolve to a URI that is a locator, the 593 interpretation of the q-component is undefined by this specification. 594 For URNs which may be resolved to a URI that is a locator, the 595 semantics of the q-component are identical to those for queries to 596 the resource located via that URI. 598 For the sake of consistency with RFC 3986, the general syntax and the 599 semantics of q-components are not defined by, or dependent on, the 600 URN namespace of the URN. In parallel with RFC 3986, specifics of 601 syntax and semantics, e.g., which keywords or terms are meaningful, 602 of course may depend on a particular URN namespace or even a 603 particular resource. 605 The sequence "?=" introduces the q-component. The q-component 606 terminates when a "#" character (number sign, which begins an 607 f-component) appears. If that character does not appear, the 608 q-component continues to the end of the URN. The characters slash 609 ("/") and question mark ("?") may represent data within the 610 q-component. Note that characters outside the ASCII range [RFC20] 611 MUST be percent-encoded using the method defined in Section 2.1 of 612 the generic URI specification [RFC3986]. 614 As described in Section 3, the q-component SHALL NOT be taken into 615 account when determining URN-equivalence. 617 URN namespaces and associated information placement in syntax SHOULD 618 be designed to avoid any need for a resolution service to consider 619 the q-component. Namespace-specific and more generic resolution 620 systems MUST NOT require that q-component information be passed to 621 them for processing. 623 Consider the hypothetical example of passing parameters to an 624 application that returns weather reports from different regions or 625 for different time periods. This could perhaps be accomplished by 626 specifying latitude and longitude coordinates and datetimes in the 627 URN's q-component, resulting in URNs such as the following. 629 urn:example:weather?=op=map&lat=39.56 630 &lon=-104.85&datetime=1969-07-21T02:56:15Z 632 If this example resolved to an HTTP URI, the result might look like: 634 https://weatherapp.example?op=map&lat=39.56 635 &lon=-104.85&datetime=1969-07-21T02:56:15Z 637 2.3.3. f-component 639 The f-component is intended to be interpreted by the client as a 640 specification for a location within, or region of, the named 641 resource. It distinguishes the constituent parts of a resource named 642 by a URN. For a URN that resolves to one or more locators which can 643 be dereferenced to a representation, or where the URN resolver 644 directly returns a representation of the resource, the semantics of 645 an f-component are defined by the media type of the representation. 647 The URN f-component has the same syntax as the URI fragment 648 component. If a URN containing an f-component resolves to a single 649 URI that is a locator associated with the named resource, the 650 f-component from the URN can be applied (usually by the client) as 651 the fragment of that URI. If the URN does not resolve to a URI that 652 is a locator, the interpretation of the f-component is undefined by 653 this specification. Thus, for URNs which may be resolved to a URI 654 that is a locator, the semantics of f-components are identical to 655 those of fragments for that resource. 657 For the sake of consistency with RFC 3986, neither the general syntax 658 nor the semantics of f-components are defined by, or dependent on, 659 the URN namespace of the URN. In parallel with RFC 3986, specifics 660 of syntax and semantics, e.g., which keywords or terms are 661 meaningful, of course may depend on a particular URN namespace or 662 even a particular resource. 664 The f-component is introduced by the number sign ("#") character and 665 terminated by the end of the URI. Any characters outside the ASCII 666 range [RFC20] that appear in the f-component MUST be percent-encoded 667 using the method defined in Section 2.1 of the generic URI 668 specification [RFC3986]. 670 As described under Section 3, the f-component SHALL NOT be taken into 671 account when determining URN-equivalence. 673 Clients SHOULD NOT pass f-components to resolution services unless 674 those services also perform object retrieval and interpretation 675 functions. 677 Consider the hypothetical example of obtaining resources that are 678 part of a larger entity (say, the chapters of a book). Each part 679 could be specified in the f-component, resulting in URNs such as: 681 urn:example:foo-bar-baz-qux#somepart 683 3. URN-Equivalence 685 3.1. Procedure 687 For various purposes such as caching, it is often desirable to 688 determine if two URNs are "the same". This is done most generally 689 (i.e., independent of the scheme) by testing for equivalence (see 690 Section 6.1 of [RFC3986]). 692 The generic URI specification [RFC3986] is very flexible about 693 equality comparisons, putting the focus on allowing false negatives 694 and avoiding false positives. If comparisons are made in a scheme- 695 independent way, i.e., as URI comparisons only, many URNs that this 696 specification considers equal would be rejected. The discussion 697 below applies when the URIs involved are known to be URNs, and thus 698 uses the terms "URN-equivalent" and "URN-equivalence" to refer to 699 equivalence as specified in this document. 701 Two URNs are URN-equivalent if their portions are 702 octet-by-octet equal after applying case normalization (as specified 703 in Section 6.2.2.1 of [RFC3986]) to the following constructs: 705 1. the URI scheme "urn", by conversion to lower case 707 2. the NID, by conversion to lower case 708 3. any percent-encoded characters in the NSS (that is, all character 709 triplets that match the production found in 710 Section 2.1 of the base URI specification [RFC3986]), by 711 conversion to upper case for the digits A-F. 713 Percent-encoded characters MUST NOT be decoded, i.e., percent- 714 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 715 MUST NOT be applied as part of the comparison process. 717 If an r-component, q-component, or f-component (or any combination 718 thereof) is included in a URN, it MUST be ignored for purposes of 719 determining URN-equivalence. 721 URN namespace definitions MAY include additional rules for URN- 722 equivalence, such as case-insensitivity of the NSS (or parts 723 thereof). Such rules MUST always have the effect of eliminating some 724 of the false negatives obtained by the procedure above and MUST NOT 725 result in treating two URNs as not "the same" if the procedure here 726 says they are URN-equivalent. For related considerations with regard 727 to NID registration, see below. 729 3.2. Examples 731 This section shows a variety of URNs (using the "example" NID defined 732 in [RFC6963]) that highlight the URN-equivalence rules. 734 First, because the scheme and NID are case-insensitive, the following 735 three URNs are URN-equivalent to each other: 737 o urn:example:a123,z456 739 o URN:example:a123,z456 741 o urn:EXAMPLE:a123,z456 743 Second, because the r-component, q-component, and f-component are not 744 taken into account for purposes of testing URN-equivalence, the 745 following three URNs are URN-equivalent to the first three examples 746 above: 748 o urn:example:a123,z456?+abc 750 o urn:example:a123,z456?=xyz 752 o urn:example:a123,z456#789 754 Third, because the "/" character (and anything that follows it) in 755 the NSS is taken into account for purposes of URN-equivalence, the 756 following URNs are not URN-equivalent to each other or to the six 757 preceding URNs: 759 o urn:example:a123,z456/foo 761 o urn:example:a123,z456/bar 763 o urn:example:a123,z456/baz 765 Fourth, because of percent-encoding, the following URNs are URN- 766 equivalent only to each other and not to any of those above (note 767 that, although %2C is the percent-encoded transformation of "," from 768 the previous examples, such sequences are not decoded for purposes of 769 testing URN-equivalence): 771 o urn:example:a123%2Cz456 773 o URN:EXAMPLE:a123%2cz456 775 Fifth, because characters in the NSS other than percent-encoded 776 sequences are treated in a case-sensitive manner (unless otherwise 777 specified for the URN namespace in question), the following URNs are 778 not URN-equivalent to the first three URNs: 780 o urn:example:A123,z456 782 o urn:example:a123,Z456 784 Sixth, on casual visual inspection of a URN presented in a human- 785 oriented interface the following URN might appear the same as the 786 first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be 787 confused with U+0061 LATIN SMALL LETTER A), but it is not URN- 788 equivalent to the first three URNs: 790 o urn:example:%D0%B0123,z456 792 4. URI Conformance 794 4.1. Use in URI Protocol Slots 796 Because a URN is, syntactically, a URI under the "urn" scheme, in 797 theory a URN can be placed in any protocol slot that allows for a URI 798 (to name just a few, the 'href' and 'src' attributes in HTML, the 799 element in HTML, the 'xml:base' attribute in XML [XML-BASE], 800 and the 'xmlns' attribute in XML for XML namespace names 801 [XML-NAMES]). 803 However, this does not imply that, semantically, it always makes 804 sense in practice to place a URN in a given URI protocol slot; in 805 particular, because a URN might not specify the location of a 806 resource or even point indirectly to one, it might not be appropriate 807 to place a URN in a URI protocol slot that points to a resource 808 (e.g., the aforementioned 'href' and 'src' attributes). 810 Ultimately, guidelines regarding when it is appropriate to use URIs 811 under the "urn" scheme (or any other scheme) are the responsibility 812 of specifications for individual URI protocol slots (e.g., the 813 specification for the 'xml:base' attribute in XML might recommend 814 that it is inappropriate to use URNs in that protocol slot). This 815 specification cannot possibly anticipate all of the relevant cases, 816 and it is not the place of this specification to require or restrict 817 usage for individual protocol slots. 819 4.2. Parsing 821 In part because of the separation of URN semantics from more general 822 URI syntax, generic URI processors need to pay special attention to 823 the parsing and analysis rules of RFC 3986 and, in particular, must 824 treat the URI as opaque unless the scheme and its requirements are 825 recognized. In the latter case, such processors may be in a position 826 to invoke scheme-appropriate processing, e.g., by a URN resolver. A 827 URN resolver can either be an external resolver that the URI resolver 828 knows of, or it can be functionality built into the URI resolver. 829 Note that this requirement might impose constraints on the contexts 830 in which URNs are appropriately used; see Section 4.1. 832 4.3. URNs and Relative References 834 Section 5.2 of [RFC3986] describes an algorithm for converting a URI 835 reference that might be relative to a given base URI into "parsed 836 components" of the target of that reference, which can then be 837 recomposed per RFC 3986 Section 5.3 into a target URI. This 838 algorithm is problematic for URNs because their syntax does not 839 support the necessary path components. However, if the algorithm is 840 applied independent of a particular scheme, it should work 841 predictably for URNs as well, with the following understandings 842 (syntax production terminology taken from RFC 3986): 844 1. A system that encounters a that obeys the syntax 845 for , whether it explicitly has the scheme "urn" or 846 not, will convert it into a target URI as specified in RFC 3986. 848 2. Because of the persistence and stability expectations of URNs, 849 authors of documents, etc., that utilize URNs should generally 850 avoid the use of the "urn" scheme in any that is 851 not strictly a as specified in RFC 3986, specifically 852 including those that would require processing of . 854 4.4. Transport and Display 856 When URNs are transported and exchanged, they MUST be represented in 857 the format defined herein. Further, all URN-aware applications MUST 858 offer the option of displaying URNs in this canonical form to allow 859 for direct transcription (for example by copy-and-paste techniques). 860 Such applications might support display of URNs in a more human- 861 friendly form and might use a character set that includes characters 862 that are not permitted in URN syntax as defined in this specification 863 (e.g., when displaying URNs to humans, such applications might 864 replace percent-encoded strings with characters from an extended 865 character repertoire such as Unicode [UNICODE]). 867 To minimize user confusion, any application displaying URIs SHOULD 868 display the complete URI (including, for URNs, the "urn" scheme and 869 any components) to ensure that there is no confusion between URN NIDs 870 and URI scheme identifiers. For example, a URI beginning with 871 "urn:xmpp:" [RFC4854] is very different from a URI beginning with 872 "xmpp:" [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] 873 is different from, and possibly completely unrelated to, a possible 874 DOI URN namespace. 876 4.5. URI Design and Ownership 878 As mentioned, the assignment of URNs within a URN namespace is a 879 managed process, as is the assignment of URN namespaces themselves. 880 Although design of the URNs to be assigned within a given URN 881 namespace is ceded by this specification to the URN namespace 882 manager, doing so in a managed way avoids the problems inherent in 883 unmanaged generation of URIs as described in the recommendations 884 regarding URI design and ownership [RFC7320]. 886 5. URN Namespaces 888 A URN namespace is a collection of names that obey three constraints: 889 each name is (1) unique, (2) assigned in a consistent way, and (3) 890 assigned according to a common definition. 892 1. The "uniqueness" constraint means that a name within the URN 893 namespace is never assigned to more than one resource and never 894 reassigned to a different resource (for the kind of "resource" 895 identified by URNs assigned within the URN namespace). This 896 holds true even if the name itself is deprecated or becomes 897 obsolete. 899 2. The "consistent assignment" constraint means that a name within 900 the URN namespace is assigned by an organization or created in 901 accordance with a process or algorithm that is always followed. 903 3. The "common definition" constraint means that there are clear 904 definitions for the syntax of names within the URN namespace and 905 for the process of assigning or creating them. 907 A URN namespace is identified by a particular NID in order to ensure 908 the global uniqueness of URNs and, optionally, to provide a cue 909 regarding the structure of URNs assigned within a URN namespace. 911 With regard to global uniqueness, using different NIDs for different 912 collections of names ensures that no two URNs will be the same for 913 different resources, because each collection is required to uniquely 914 assign each name. However, a single resource MAY have more than one 915 URN assigned to it, either in the same URN namespace (if the URN 916 namespace permits it) or in different URN namespaces, and either for 917 similar purposes or different purposes. (For example, if a publisher 918 assigns an ISBN [RFC3187] to an electronic publication and that 919 publication is later incorporated into a digital long-term archive 920 operated by a national library, the library might assign the 921 publication an NBN [RFC3188], resulting in two URNs referring to the 922 same book.) Subject to other constraints, such as those imposed by 923 the URI syntax [RFC3986], the rules of the URN scheme are intended to 924 allow preserving the normal and natural form of names specified in 925 non-URN identifier systems when they are treated as URNs. 927 With regard to the structure of names assigned within a URN 928 namespace, the development of a naming structure (and thereby a 929 collection of names) depends on the requirements of the community 930 defining the names, how the names will be assigned and used, etc. 931 These issues are beyond the scope of URN syntax and the general rules 932 for URN namespaces, because they are specific to the community 933 defining a non-URN identifier system or a particular URN namespace 934 (e.g., the bibliographic and publishing communities in the case of 935 the 'ISBN' URN namespace [RFC3187] and the 'ISSN' URN namespace 936 [RFC3044], or the developers of extensions to the Extensible 937 Messaging and Presence Protocol [RFC6120] in the case of the 'XMPP' 938 URN namespace [RFC4854]). 940 Because the colon character (":") is used to separate "urn" from the 941 NID and the NID from the NSS, it's tempting to think of the entire 942 URN as being structured by colon characters, and to assume that 943 colons create a structure or hierarchy within the NSS portion of the 944 URN. Such structure could be specified by a particular NID 945 specification, but there is no implicit structure. In a URN such as 946 urn:example:apple:pear:plum:cherry 948 the NSS string is "apple:pear:plum:cherry" as a whole, and there is 949 no specific meaning to the colon characters within that NSS string 950 unless such meaning is described in the specification of the 951 "example" namespace. 953 URN namespaces inherit certain rights and responsibilities by the 954 nature of URNs, in particular: 956 1. They uphold the general principles of a well-managed URN 957 namespace by providing persistent identification of resources and 958 unique assignment of names in accordance with a common 959 definition. 961 2. Optionally, they can be registered in global registration 962 services such as those described in [RFC2483]. 964 There are two types of URN namespace: formal and informal. These are 965 distinguished by the expected level of service, the information 966 needed to define the URN namespace, and the procedures for 967 registration. Because the majority of the URN namespaces registered 968 so far have been formal, this document concentrates on formal URN 969 namespaces. 971 5.1. Formal URN Namespaces 973 A formal URN namespace provides benefit to some subset of users on 974 the Internet. In particular, it would not make sense for a formal 975 URN namespace to be used only by a community or network that is not 976 connected to the Internet. For example, it would be inappropriate 977 for a URN namespace to effectively force someone to use a proprietary 978 network or service not open to the general Internet user. The intent 979 is that, while the community of those who might actively use the URNs 980 assigned within that URN namespace might be small, the potential use 981 of names within that URN namespace is open to any user on the 982 Internet. Formal URN namespaces might be appropriate even when some 983 aspects are not fully open. For example, a URN namespace might make 984 use of a fee-based, privately managed, or proprietary registry for 985 assignment of URNs in the URN namespace. However, it might still 986 benefit some Internet users if the associated services have openly- 987 published names. 989 An organization that will assign URNs within a formal URN namespace 990 SHOULD meet the following criteria: 992 1. Organizational stability and the ability to maintain the URN 993 namespace for a long time; absent such evidence, it ought to be 994 clear how the URN namespace can remain viable if the organization 995 can no longer maintain the URN namespace. 997 2. Competency in URN assignment. This will improve the likelihood 998 of persistence (e.g., to minimize the likelihood of conflicts). 1000 3. Commitment to not reassigning existing URNs and to allowing old 1001 URNs to continue to be valid (e.g., if the assignee of a URN is 1002 no longer a member or customer of the assigning organization, if 1003 various information about the assignee or named entity happens to 1004 change, or even if the assignee or the named entity itself is no 1005 longer in existence; in all these cases, the URN is still valid). 1007 A formal URN namespace establishes a particular NID, subject to the 1008 following constraints (above and beyond the syntax rules already 1009 specified): 1011 1. It MUST NOT be an already-registered NID. 1013 2. It MUST NOT start with "urn-" (which is reserved for informal URN 1014 namespaces). 1016 3. It MUST be more than two characters long and it MUST NOT start 1017 with ALPHA ALPHA "-", i.e., any string consisting of two letters 1018 followed by one hyphen; such strings are reserved for potential 1019 use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for 1020 eventual national registrations of URN namespaces (however, the 1021 definition and scoping of rules for allocation of responsibility 1022 for such country-code-based URN namespaces are beyond the scope 1023 of this document). As a consequence, it MUST NOT start with the 1024 string "xn--" or any other string consisting of two letters 1025 followed by two hyphens; such strings are reserved for potential 1026 representation of DNS A-labels and similar strings in the future 1027 [RFC5890]. 1029 4. It MUST NOT start with the string "X-" so that it will not be 1030 confused with or conflict any experimental URN namespace 1031 previously permitted by [RFC3406]. 1033 Applicants and reviewers considering new NIDs should also be aware 1034 that they may have semantic implications and hence be a source of 1035 conflict. Particular attention should be paid to strings that might 1036 be construed as identifiers for, or registered under the authority 1037 of, countries (including ISO 3166-1 alpha-3 codes) and to strings 1038 that might imply association with existing URI schemes, non-URN 1039 identifier systems, or trademarks. However, in line with traditional 1040 policies, disputes about "ownership" of particular strings are 1041 disagreements among the parties involved; neither IANA nor the IETF 1042 will become involved in such disputes except in response to orders 1043 from a court of competent jurisdiction. 1045 5.2. Informal URN Namespaces 1047 Informal URN namespaces are full-fledged URN namespaces, with all the 1048 associated rights and responsibilities. Informal URN namespaces 1049 differ from formal URN namespaces in the process for assigning a NID: 1050 for an informal URN namespace, the registrant does not designate the 1051 NID; instead, IANA assigns a NID consisting of the string 'urn-' 1052 followed by one or more digits (e.g., "urn-7") where the digits 1053 consist of the next available number in the sequence of positive 1054 integers assigned to informal URN namespaces. Thus the syntax of an 1055 informal URN namespace identifier is: 1057 InformalNamespaceName = "urn-" Number 1058 Number = DigitNonZero 0*Digit 1059 DigitNonZero = "1"/ "2" / "3" / "4"/ "5" 1060 / "6" / "7" / "8" / "9" 1061 Digit = "0" / DigitNonZero 1063 The only restrictions on are that it (1) consist strictly of 1064 ASCII digits, that it (2) not have leading zeros, and that it (3) not 1065 cause the NID to exceed the length limitations defined for the URN 1066 syntax (see Section 2). 1068 6. Defining and Registering a URN Namespace 1070 6.1. Overview 1072 Because the space of URN namespaces is itself managed, the definition 1073 of a URN namespace SHOULD pay particular attention to: 1075 1. The purpose of the URN namespace. 1077 2. The syntax of URNs assigned within the URN namespace, including 1078 the internal syntax and anticipated effects of r-components or 1079 q-components. (The syntax and interpretation of f-components are 1080 defined in RFC 3986.) 1082 3. The process for assigning URNs within the URN namespace. 1084 4. The security implications of assigning URNs within the URN 1085 namespace and of using the assigned URNs. 1087 5. Any potential interoperability issues with URNs assigned within 1088 the URN namespace. 1090 6. Optionally, the process for resolving URNs issued within the URN 1091 namespace. 1093 The section on completing the template (Section 6.4) explains these 1094 matters in greater detail. Although the registration templates are 1095 the same in all cases, slightly different procedures are used 1096 depending on the source of the registration. 1098 6.2. Registration Policy and Process: Community Registrations 1100 The basic registration policy for URN namespaces is Expert Review as 1101 defined in the "IANA Considerations" document [RFC5226]. For URN 1102 namespaces or their definitions that are intended to become standards 1103 or constituent parts of standards, the output of the Expert Review 1104 process is intended to be a report, rather than instructions to IANA 1105 to take action (see below). The key steps are: 1107 1. Fill out the URN namespace registration template (see Section 6.4 1108 and Appendix A). This can be done as part of an Internet-Draft 1109 or a specification in another series, although that is not a 1110 requirement. 1112 2. Send the completed template to the urn@ietf.org discussion list 1113 for review. 1115 3. If necessary to address comments received, repeat steps 1 and 2. 1117 4. If the designated experts approve the request and no 1118 standardization action is involved, the IANA will register the 1119 requested NID. If standardization is anticipated, the designated 1120 experts will prepare a report and forward it to the appropriate 1121 standards approval body (the IESG in the case of the IETF); IANA 1122 will register the requested NID only after receiving directions 1123 from that body and a copy of the expert review report. 1125 A URN namespace registration can be revised by updating the 1126 registration template, following the same steps outlined above for 1127 new registrations. A revised registration MUST describe differences 1128 from prior versions and SHOULD make special note of any relevant 1129 changes in the underlying technologies or URN namespace management 1130 processes. 1132 Experience to date with URN namespace registration requests has shown 1133 that registrants sometimes do not initially understand some of the 1134 subtleties of URN namespaces, and that defining the URN namespace in 1135 the form of a specification enables the registrants to clearly 1136 formulate their "contract" with the intended user community. 1137 Therefore, although the registration policy for formal URN namespaces 1138 is Expert Review and a specification (as distinct from the 1139 registration template) is not strictly required, registrants SHOULD 1140 provide a stable specification documenting the URN namespace 1141 definition and expanding upon the issues described herein. 1143 Because naming can be difficult and contentious, URN namespace 1144 registrants and the designated experts are strongly encouraged to 1145 work together in a spirit of good faith and mutual understanding to 1146 achieve rough consensus (see [RFC7282]) on handling registration 1147 requests. They are also encouraged to bring additional expertise 1148 into the discussion if that would be helpful in providing perspective 1149 or otherwise resolving issues. 1151 Especially when iterations in the registration process are prolonged, 1152 designated experts are expected to take reasonable precautions to 1153 avoid "race conditions" on proposed NIDs and, if such situations 1154 arise, to encourage applicants to work out any conflicts among 1155 themselves. 1157 6.3. Registration Policy and Process: Fast Track for Standards 1158 Development Organizations, Scientific Societies, and Similar 1159 Bodies 1161 The IETF recognizes that situations will arise in which URN 1162 namespaces will be created to either embed existing and established 1163 standards, particularly identifier standards, or to reflect 1164 knowledge, terminology, or methods of organizing information that lie 1165 well outside the IETF's scope or the likely subject matter knowledge 1166 of its designated experts. In situations in which the registration 1167 request originates from, or is authorized by, a recognized standards- 1168 related organization, scientific society, or similar body, a somewhat 1169 different procedure is available at the option of that body: 1171 1. The URN namespace registration template is filled out and 1172 submitted as in steps 1 and 2 of Section 6.2. 1174 2. A specification is required that reflects or points to the needed 1175 external standards or specifications. Publication in the RFC 1176 Series or through an IETF process (e.g., posting as an Internet 1177 Draft) is not expected and would be appropriate only under very 1178 unusual circumstances. 1180 3. The reviews on the discussion list and by the designated experts 1181 are strictly advisory, with the decisions about what advice to 1182 accept and the length of time to allocate to the process strictly 1183 under the control of the external body. 1185 4. When that body concludes that the application is sufficiently 1186 mature, its representative(s) will request that IANA complete the 1187 registration for the NID, and IANA will do so. 1189 Decisions about whether to recognize the requesting entity as a 1190 standards-related organization, scientific society, or similar body 1191 are the responsibility of the IESG. 1193 A model similar to this has already been defined for recognized 1194 standards-related organizations that wish to register Media Types. 1195 The document describing that mechanism [RFC6838] provides somewhat 1196 more information about the general approach. 1198 6.4. Completing the Template 1200 A template for defining and registering a URN namespace is provided 1201 in Appendix A. This section describes considerations for completing 1202 the template. 1204 6.4.1. Purpose 1206 The "Purpose" section of the template describes matters such as: 1208 1. The kinds of resources identified by URNs assigned within the URN 1209 namespace. 1211 2. The scope and applicability of the URNs assigned within the URN 1212 namespace; this might include information about the community of 1213 use (e.g., a particular nation, industry, technology, or 1214 organization), whether the assigned URNs will be used on public 1215 networks or private networks, etc. 1217 3. How the intended community (and the Internet community at large) 1218 will benefit from using or resolving the assigned URNs. 1220 4. How the URN namespace relates to and complements existing URN 1221 namespaces, URI schemes, and non-URN identifier systems. 1223 5. The kinds of software applications that can use or resolve the 1224 assigned URNs (e.g., by differentiating among disparate URN 1225 namespaces, identifying resources in a persistent fashion, or 1226 meaningfully resolving and accessing services associated with the 1227 URN namespace). 1229 6. Whether resolution services are available or will be available 1230 (and, if so, the nature or identity of the services). Examples 1231 of q-component and (when they are standardized) r-component 1232 semantics and syntax are helpful here, even if detailed 1233 definitions are provided elsewhere or later. 1235 7. Whether the URN namespace or its definition is expected to become 1236 a constituent part of a standard being developed in the IETF or 1237 some other recognized standards body. 1239 6.4.2. Syntax 1241 The "Syntax" section of the template contains: 1243 1. A description of the structure of URNs within the URN namespace, 1244 in conformance with the fundamental URN syntax. The structure 1245 might be described in terms of a formal definition (e.g., using 1246 Augmented BNF for Syntax Specifications (ABNF) [RFC5234]), an 1247 algorithm for generating conformant URNs, or a regular expression 1248 for parsing the name into consituent parts; alternatively, the 1249 structure might be opaque. 1251 2. Any special character encoding rules for assigned URNs (e.g., 1252 which character ought to always be used for quotes). 1254 3. Rules for determining URN-equivalence between two names in the 1255 URN namespace. Such rules ought to always have the effect of 1256 eliminating false negatives that might otherwise result from 1257 comparison. If it is appropriate and helpful, reference can be 1258 made to particular equivalence rules defined in the URI 1259 specification [RFC3986] or to Section 3 of this document. 1260 Examples of URN-equivalence rules include equivalence between 1261 uppercase and lowercase characters in the NSS, between hyphenated 1262 and non-hyphenated groupings in the name, or between single- 1263 quotes and double-quotes. There may also be namespace-specific 1264 special encoding considerations, especially for URNs that contain 1265 embedded forms of names from non-URN identifier systems. (Note 1266 that these are not normative statements for any kind of best 1267 practice related to handling of relationships between characters 1268 in general; such statements are limited to one particular URN 1269 namespace only.) 1271 4. Any special considerations necessary for conforming with the URN 1272 syntax. This is particularly applicable in the case of existing, 1273 non-URN identifier systems that are used in the context of URNs. 1274 For example, if a non-URN identifier system is used in contexts 1275 other than URNs, it might make use of characters that are 1276 reserved in the URN syntax. This section ought to note any such 1277 characters, and outline necessary mappings to conform to URN 1278 syntax. Normally, this will be handled by percent-encoding the 1279 character as specified in Section 2.1 of the URI specification 1281 [RFC3986] and as discussed in Section 1.2.2 of this 1282 specification. 1284 5. Any special considerations for the meaning of q-components (e.g., 1285 keywords) or f-components (e.g., predefined terms) in the context 1286 of this URN namespace. 1288 6.4.3. Assignment 1290 The "Assignment" section of the template describes matters such as: 1292 1. Mechanisms or authorities for assigning URNs to resources. It 1293 ought to make clear whether assignment is completely open (e.g., 1294 following a particular procedure such as first-come, first-served 1295 (FCFS)), completely closed (e.g., for a private organization), or 1296 limited in various ways (e.g., delegated to authorities 1297 recognized by a particular organization); if limited, it ought to 1298 explain how to become an assigner of names or how to request 1299 assignment of names from existing assignment authorities. 1301 2. Methods for ensuring that URNs within the URN namespace are 1302 unique. For example, names might be assigned sequentially or in 1303 accordance with some well-defined process by a single authority, 1304 assignment might be partitioned among delegated authorities that 1305 are individually responsible for respecting uniqueness rules, or 1306 URNs might be created independently following an algorithm that 1307 itself guarantees uniqueness. 1309 6.4.4. Security and Privacy 1311 The "Security and Privacy" section of the template describes any 1312 potential issues related to security and privacy with regard to 1313 assignment, use, and resolution of names within the URN namespace. 1314 Examples of such issues include: 1316 o The consequences of producing false negatives and false positives 1317 during comparison for URN-equivalence (see Section 1.2.2 of this 1318 specification and "Issues in Identifier Comparison for Security 1319 Purposes" [RFC6943]). 1321 o Leakage of private information when names are communicated on the 1322 public Internet. 1324 o The potential for directory harvesting. 1326 o Various issues discussed in the guidelines for security 1327 considerations in RFCs [RFC3552] and the privacy considerations 1328 for Internet protocols [RFC6973]. 1330 6.4.5. Interoperability 1332 The "Interoperability" section MUST specify any known potential 1333 issues related to interoperability. Examples include possible 1334 confusion with other URN namespaces, non-URN identifier systems, or 1335 URI schemes because of syntax (e.g., percent-encoding of certain 1336 characters) or scope (e.g., overlapping areas of interest). If at 1337 all possible, concerns that arise during the registration of a URN 1338 namespace (e.g., due to the syntax or scope of a non-URN identifier 1339 system) should be resolved as part of or in parallel to the 1340 registration process. 1342 6.4.6. Resolution 1344 The "Resolution" section MUST specify whether resolution mechanisms 1345 are intended or anticipated for URNs assigned within the URN 1346 namespace. 1348 If resolution is intended, then this section SHOULD specify whether 1349 the organization that assigns URNs within the URN namespace intends 1350 to operate or recommend any resolution services for URNs within that 1351 URN namespace. In addition, if the assigning organization intends to 1352 implement registration for publicly advertised resolution services 1353 (for example using a system based on principles similar to those 1354 described in [RFC2276] and [RFC2483]), then this section SHOULD list 1355 or reference the requirements for being publicly advertised by the 1356 assigning organization. In addition, this section SHOULD describe 1357 any special considerations for the handling of r-components in the 1358 context of this URN namespace. 1360 6.4.7. Additional Information 1362 The "Additional Information" section includes information that would 1363 be useful to those trying to understand this registration or its 1364 relationship to other registrations, such as comparisons to existing 1365 URN namespaces that might seem to overlap. 1367 This section of the template is optional. 1369 7. IANA Considerations 1371 7.1. URI Scheme 1373 This section updates the registration of the 'urn' URI scheme in the 1374 Permanent URI Registry [URI-Registry]. 1376 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 1377 and the number assigned to this document upon publication.] 1378 URI Scheme Name: urn 1380 Status: permanent 1382 URI Scheme Syntax: See Section 2 of [ this document ]. 1384 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 1385 Names, which are persistent, location-independent resource 1386 identifiers. 1388 Encoding Considerations: See Section 2 of [ this document ]. 1390 Applications/Protocols That Use This URI Scheme Name: Uniform 1391 Resource Names are used in a wide variety of applications, 1392 including bibliographic reference systems and as names for 1393 Extensible Markup Language (XML) namespaces. 1395 Interoperability Considerations: See Section 4 of [ this document ]. 1397 Security Considerations: See Section 6.4.4 and Section 8 of [ this 1398 document ]. 1400 Contact: URNBIS WG [mailto:urn@ietf.org] 1402 Author/Change Controller: This scheme is registered under the IETF 1403 tree. As such, the IETF maintains change control. 1405 References None. 1407 7.2. Registration of URN Namespaces 1409 This document outlines the processes for registering URN namespaces, 1410 and has implications for the IANA in terms of registries to be 1411 maintained (see especially Section 6). In all cases, the IANA ought 1412 to assign the appropriate NID (formal or informal) once the 1413 procedures outlined in Section 6 above have been completed. 1415 8. Security and Privacy Considerations 1417 The definition of a URN namespace needs to account for potential 1418 security and privacy issues related to assignment, use, and 1419 resolution of names within the URN namespace (e.g., some URN 1420 resolvers might assign special meaning to certain characters in the 1421 NSS); see Section 6.4.4 for further discussion. 1423 In most cases, URN namespaces provide a way to declare public 1424 information. Normally, these declarations will have a relatively low 1425 security profile, however there is always the danger of "spoofing" 1426 and providing misinformation. Information in these declarations 1427 ought to be taken as advisory. 1429 9. References 1431 9.1. Normative References 1433 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 1434 October 1969. 1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1437 Requirement Levels", BCP 14, RFC 2119, March 1997. 1439 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1440 Resource Identifier (URI): Generic Syntax", STD 66, 1441 RFC 3986, January 2005. 1443 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1444 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1445 May 2008. 1447 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1448 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1450 9.2. Informative References 1452 [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The 1453 "doi" URI Scheme for the Digital Object Identifier (DOI)", 1454 June 2003, 1455 . 1457 [I-D.saintandre-iana-urn] 1458 Saint-Andre, P. and M. Cotton, "A Uniform Resource Name 1459 (URN) Namespace for IANA Registries", draft-saintandre- 1460 iana-urn-01 (work in progress), February 2013. 1462 [ISO.27729.2012] 1463 Technical Committee ISO/TC 46, Information and 1464 documentation, Subcommittee SC 9, Identification and 1465 description., "Information and documentation - 1466 International standard name identifier (ISNI)", ISO Draft 1467 Standard 27729, 03 2012. 1469 [ISO.3166-1] 1470 ISO, "Codes for the representation of names of countries 1471 and their subdivisions -- Part 1: Country codes", 1472 ISO 3166-1:2013, 2013. 1474 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1475 Uniform Resource Names", RFC 1737, December 1994. 1477 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1478 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 1479 December 1994, . 1481 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", 1482 RFC 1808, DOI 10.17487/RFC1808, June 1995, 1483 . 1485 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1487 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1488 Name Resolution", RFC 2276, January 1998. 1490 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1491 Necessary for URN Resolution", RFC 2483, January 1999. 1493 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1494 DOI 10.17487/RFC2648, August 1999, 1495 . 1497 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1498 Standard Number) as URN (Uniform Resource Names) within an 1499 ISSN-URN Namespace", RFC 3044, January 2001. 1501 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1502 Book Numbers as Uniform Resource Names", RFC 3187, October 1503 2001. 1505 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 1506 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 1507 October 2001, . 1509 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1510 "Uniform Resource Names (URN) Namespace Definition 1511 Mechanisms", BCP 66, RFC 3406, October 2002. 1513 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1514 Text on Security Considerations", BCP 72, RFC 3552, July 1515 2003. 1517 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1518 for Extensions to the Extensible Messaging and Presence 1519 Protocol (XMPP)", RFC 4854, April 2007. 1521 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1522 (IRIs) and Uniform Resource Identifiers (URIs) for the 1523 Extensible Messaging and Presence Protocol (XMPP)", 1524 RFC 5122, February 2008. 1526 [RFC5890] Klensin, J., "Internationalized Domain Names for 1527 Applications (IDNA): Definitions and Document Framework", 1528 RFC 5890, August 2010. 1530 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1531 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1532 March 2011, . 1534 [RFC6288] Reed, C., "URN Namespace for the Defence Geospatial 1535 Information Working Group (DGIWG)", RFC 6288, 1536 DOI 10.17487/RFC6288, August 2011, 1537 . 1539 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1540 "Deprecating the "X-" Prefix and Similar Constructs in 1541 Application Protocols", BCP 178, RFC 6648, June 2012. 1543 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1544 Specifications and Registration Procedures", BCP 13, 1545 RFC 6838, January 2013. 1547 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1548 Purposes", RFC 6943, May 2013. 1550 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1551 for Examples", BCP 183, RFC 6963, May 2013. 1553 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1554 Morris, J., Hansen, M., and R. Smith, "Privacy 1555 Considerations for Internet Protocols", RFC 6973, July 1556 2013. 1558 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 1559 RFC 7282, June 2014. 1561 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1562 RFC 7320, July 2014. 1564 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 1565 P. Kyzivat, "URNs for the Alert-Info Header Field of the 1566 Session Initiation Protocol (SIP)", RFC 7462, 1567 DOI 10.17487/RFC7462, March 2015, 1568 . 1570 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1571 Enforcement, and Comparison of Internationalized Strings 1572 Representing Usernames and Passwords", RFC 7613, 1573 DOI 10.17487/RFC7613, August 2015, 1574 . 1576 [UAX31] The Unicode Consortium, "Unicode Standard Annex #31: 1577 Unicode Identifier and Pattern Syntax", June 2015, 1578 . 1580 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015, 1581 . 1583 [URI-Registry] 1584 IANA, "Permanent URI Schemes", 1585 . 1588 [XML-BASE] 1589 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1590 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1591 January 2009, 1592 . 1594 [XML-NAMES] 1595 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1596 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1597 Web Consortium Recommendation REC-xml-names-20091208, 1598 December 2009, 1599 . 1601 Appendix A. Registration Template 1603 Namespace ID: Requested of IANA (formal) or assigned by IANA 1604 (informal). 1606 Version: The version of the registration, starting with 1 and 1607 incrementing by 1 with each new version. 1609 Date: The date when the registration is requested of IANA, using the 1610 format YYYY-MM-DD. 1612 Registrant: The person or organization that has registered the NID, 1613 including the name and address of the registering organization, as 1614 well as the name and contact information (email, phone number, or 1615 postal address) of the designated contact person. If the 1616 registrant is a recognized standards development organization, 1617 scientific society, or similar body requesting the fast track 1618 registration procedure (see Section 6.3), that information should 1619 be clearly indicated in this section of the template. 1621 Purpose: Described under Section 6.4.1 of this document. 1623 Syntax: Described under Section 6.4.2 of this document. Unless the 1624 registration explicitly describes the semantics of r-components, 1625 q-components, and f-components in the context of this URN 1626 namespace, those semantics are undefined. 1628 Assignment: Described under Section 6.4.3 of this document. 1630 Security and Privacy: Described under Section 6.4.4 of this 1631 document. 1633 Interoperability: Described under Section 6.4.5 of this document. 1635 Resolution: Described under Section 6.4.6 of this document. 1637 Documentation: A pointer to an RFC, a specification published by 1638 another standards development organization, or another stable 1639 document that provides further information about this URN 1640 namespace. 1642 Additional Information: Described under Section 6.4.7 of this 1643 document. 1645 Revision Information: Description of changes from prior version(s). 1646 (Applicable only when earlier registrations have been revised.) 1648 Appendix B. Changes from RFC 2141 1650 This document makes substantive changes from the syntax and semantics 1651 of [RFC2141]: 1653 B.1. Syntax changes from RFC 2141 1655 The syntax of URNs as provided in [RFC2141] was defined before the 1656 updated specification of URIs in [RFC3986]. The definition of URN 1657 syntax is updated in this document to do the following: 1659 o Ensure consistency with the URI syntax. 1661 o Facilitate the use of URNs with parameters similar to URI queries 1662 and fragments. 1664 o Permit parameters influencing URN resolution. 1666 o Ease the use of URNs with non-URN identifier systems that include 1667 the '/' character. 1669 In particular, this specification does the following: 1671 o Extends URN syntax to explicitly allow the characters '/', "?", 1672 and "#", which were reserved for future use by RFC 2141. This 1673 change effectively also allows several components of the URI 1674 syntax although without necessarily tying those components to URI 1675 semantics. 1677 o Defines general syntax for an additional component that can be 1678 used in interactions with a URN resolution service. 1680 o Disallows "-" at the end of a NID. 1682 o Allows the "/", "~", and "&" characters in the namespace-specific 1683 string (NSS). 1685 o Makes several smaller syntax adjustments. 1687 B.2. Other changes from RFC 2141 1689 o Formally registers 'urn' as a URI scheme. 1691 o Allows what are now called r-components, q-components, and 1692 f-components. 1694 In addition, some of the text has been updated to be consistent with 1695 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1696 the processes for registering information with the IANA [RFC5226], as 1697 well as more modern guidance with regard to security [RFC3552], 1698 privacy [RFC6973], and identifier comparison [RFC6943]. 1700 Appendix C. Changes from RFC 3406 1702 This document makes the following substantive changes from [RFC3406]: 1704 1. Relaxes the registration policy for formal URN namespaces from 1705 "IETF Review" to "Expert Review" as discussed in Section 6.2. 1707 2. Removes the category of experimental URN namespaces, consistent 1708 with [RFC6648]. Experimental URN namespaces were denoted by 1709 prefixing the namespace identifier with the string "X-". Because 1710 experimental URN namespaces were never registered, removing the 1711 experimental category has no impact on the existing registries. 1712 Because experimental URN namespaces are not managed, strings 1713 conforming to URN syntax within experimental URN namespaces are 1714 not valid URNs. Truly experimental usages MAY, of course, employ 1715 the 'example' namespace [RFC6963]. 1717 3. Adds some information to, but generally simplifies, the URN 1718 namespace registration template. 1720 Appendix D. Contributors 1722 RFC 2141, which provided the basis for the syntax portion of this 1723 document, was authored by Ryan Moats. 1725 RFC 3406, which provided the basis for the namespace portion of this 1726 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1727 Renato Iannella, and Patrik Faltstrom. 1729 Their work is gratefully acknowledged. 1731 Appendix E. Acknowledgements 1733 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1734 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1735 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1736 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1737 participants in the URNBIS WG for their input. Alfred Hoenes in 1738 particular edited an earlier version of this document and served as 1739 co-chair of the URNBIS WG. 1741 Juha Hakala deserves special recognition for his dedication to 1742 successfully completing this work, as do Andrew Newton and Melinda 1743 Shore in their roles as working group co-chairs and Barry Leiba in 1744 his role as area director and then as co-chair. 1746 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1748 [[RFC Editor: please remove this appendix before publication.]] 1750 F.1. Changes from -08 to -09 1752 o Altered the text in Section 4 to reflect list discussions about 1753 the earlier phrasing. Also added DOI example and citation to that 1754 section. 1756 o Clarified the naming rules for formal namespaces and their 1757 relationship to ISO 3166, IDNA, etc., reserved strings. 1759 o Added an explicit statement about use of URNs in various protocols 1760 and contexts to Section 4. 1762 o Clarified that experimental namespace NIDs, which were explicitly 1763 not registered, are not valid URNs (in Section 5. 1765 o Transformed the partial production in Section 5.2 into valid ABNF. 1767 o Added more text about p-/q-/f-components and recommendations about 1768 use. 1770 o Added clarifying note about "?" within q-components and 1771 f-components. 1773 o Added explicit requirement that revisions of existing 1774 registrations document the changes and added a slot for that 1775 description to the template. 1777 o Many small editorial changes and adjustments including adding 1778 additional references and cross-references for clarification. 1780 o Inserted a placeholder for additional examples. 1782 F.2. Changes from -09 to -10 1784 o Several clarifying editorial changes, most suggested by Ted Hardie 1785 and Henry S. Thompson (some of them off-list). 1787 o Added a large number of placeholders that identify issues that 1788 require WG consideration and resolution (or WG delegation to the 1789 editors). 1791 F.3. Changes from -10 to -11 1793 o Removed most of the placeholders added in -10. Supplied new text 1794 as required or suggested by on-list discussion of those issues. 1796 o Replaced the conformance examples Section 3.2 with a more complete 1797 collection and discussion. 1799 o Revised and consolidated the registration procedure, and added 1800 provisions for NIDs that are the subject of standards and for 1801 avoiding race conditions about NID strings. 1803 o In response to independent comments from Ted Hardie and Henry S. 1804 Thompson, called attention to the possibility of conflicts between 1805 NID strings and various claims of national, corporate, and other 1806 perogatives. 1808 o Changed the production for assigned-name as suggested by Lars 1809 Svensson. 1811 o Several clarifying editorial changes including correcting a glitch 1812 in instructions to the RFC Editor. 1814 F.4. Changes from -11 to -12 1816 o Removed p-components as a standalone construct, and instead folded 1817 them into the NSS. 1819 o Defined syntax for r-components as a way to pass information to 1820 resolvers, but left the semantics for future standardization 1821 efforts. 1823 o Further tuned the discussion of interoperability and related 1824 registration issues. 1826 o Made a number of editorial corrections and reorganized the syntax 1827 material in Section 2 somewhat to make it internally consistent 1828 and keep the relationship to RFC 3986 clear. 1830 F.5. Changes from -12 to -13 1832 o More precisely defined the semantics of the optional components. 1834 o Defined the term "resolution" and clarified several related 1835 matters throughout the text. 1837 o Clarified terminological relationship to RFC 3986. 1839 o Further cleansed the document of p-components. 1841 o Corrected several examples to avoid confusion with existing 1842 identifier systems. 1844 o Improved text regarding the purpose of namespaces being 1845 registered. 1847 F.6. Changes from -13 to -14 1849 o Reverted the ABNF to what had been defined in version -12. 1851 o Added fast-track approval process for standards-related 1852 organizations, scientific societies, and similar bodies (similar 1853 to RFC 6838 for Media Types). 1855 F.7. Changes from -14 to -15 1857 o Reorganized the Introduction slightly, adding new subsection 1.1 1858 and making Terminology (the former Section 2) Section 1.2. 1860 o Tightened the discussion of "resolution" somewhat to try to 1861 mitigate some on-list confusion. 1863 o Added some text about character set choices and repertoires 1864 (consistent with the Section 1.1 explanation). 1866 o Moved away from "?" and "??" for q-component and r-component 1867 delimiters and went to two-character sequences for each. This 1868 includes several changes to the text to remove or modify 1869 discussions of string termination and the role of a question mark 1870 not followed by one of the new delimiters. 1872 o Redefined r-component to be an ASCII resolver ID and a string. 1873 Neither is further defined in this specification and text has been 1874 added to say that. 1876 o Several editorial changes to improve clarity, most following up on 1877 comments made on the list. These included modifying the table of 1878 contents so that the subsections on optional components now appear 1879 there. 1881 F.8. Changes from -15 (2016-02-04) to -16 1883 o Rewrote the introductory material to make the relationship to 1884 other specifications more clear and allow removing or altering 1885 text that was stated in terms of changes from 2141. The 1886 specification is now self-contained with regard to the earlier 1887 definitions and descriptions of URNs. 1889 o Removed the parts of Section 2 that were really a description of 1890 changes from RFC 2141 to Appendix B, where such changes are 1891 enumerated. Similarly, removed most material describing changes 1892 from RFC 3406 to Appendix C. 1894 o Replaced one example. 1896 o Rearranged and rewrote text to improve clarity and relationships 1897 to other documents and to reduce redundant material. 1899 o Made it more clear that r-components, despite the partial syntax 1900 specification, are reserved for future standardization. 1902 o Clarified that there can be URNs that do not resolve to URLs. 1904 o Added pointers to make it clear that the Syntax material in 1905 Section 2 is not self-contained, e.g., that its subsections and 1906 other sections further restrict strings that can be used for NIDs 1907 and so on. 1909 o Added an "Additional Information" section to the registration 1910 template. See list discussion on and about 2016-03-18. 1912 o Minor editorial/ typographic fixes (per comment from Lars). 1914 F.9. Changes from -16 (2016-04-16) to -17 1916 o Clarified material about copying q-components, including adding an 1917 example. 1919 o Modified the document in several places to try to respond to 1920 concerns about the unqualified use of the term "equivalence". The 1921 term has been eliminated in one or two places and changed to "URN- 1922 equivalence" in situations in which the scheme is known and URN- 1923 specific rules are being applied. 1925 o Editorial and typographic fixes. 1927 o Temporarily (this version only) added [[CREF...]] placeholders to 1928 identify outstanding issues that might usefully be discussed 1929 during the 2016-06-29 virtual meeting but that must be resolved in 1930 some way for the document to move forward. 1932 F.10. Changes from -17 (2016-06-27) to -18 1934 o Removed "cref placeholders" inserted for -17 and the 2016-06-29 1935 virtual meeting. 1937 o Per interim meeting 2016-06-29, changed "equivalent" and 1938 "equivalence" to "URN-equivalent" and "URN-equivalence" in a 1939 number of locations. 1941 o Per interim meeting 2016-06-29 and previous list discussion, 1942 clarified the usage of the terms 'name', 'namespace', 'URN 1943 namespace', 'identifier system', 'URN', and 'NSS'. 1945 o Per interim meeting 2016-06-29, changed syntax so that r-component 1946 precedes q-component. 1948 F.11. Changes from -18 (2016-09-05) to -19 1950 o Small editorial changes to improve clarity. 1952 o Added cross-references to material, especially in Section 6 and as 1953 derived from RFC 3406. 1955 o Replaced material on relative references to reflect the on-list 1956 discussions in August and September and generally to say less here 1957 and leave more to RFC 3986. 1959 o Expanded the discussion of resolution, dereferencing, 1960 representations, metadata, and intended uses for URNs. 1962 o Removed the term "abstract designator". 1964 o Replaced the term "URL" in most instances with the term "locator" 1965 or the phrase "URI that is a locator". 1967 o Rearranged and partially rewrote the "Terminology" section to 1968 reflect the above change to "URL" usage, reflect the actual use of 1969 the term "URN" in the document, and be clear about the meaning (or 1970 lack thereof) of "name". 1972 F.12. Changes from -19 (2016-12-31) to -20 1974 o After getting permission from Ryan Moats, author of RFC 2141, 1975 changed the IPR status to reflect current preferred rights. 1977 o Added text to clarify the role of ":" inside the NSS. 1979 o Removed the reference to the semantics clarification I-D from the 1980 draft, as discussed on the mailing list. 1982 o Corrected two remaining instances of "3896" rather than "3986". 1984 Authors' Addresses 1986 Peter Saint-Andre 1987 Filament 1988 P.O. Box 787 1989 Parker, CO 80134 1990 USA 1992 Email: peter@filament.com 1993 URI: https://filament.com/ 1994 John C Klensin 1995 1770 Massachusetts Ave, Ste 322 1996 Cambridge, MA 02140 1997 USA 1999 Phone: +1 617 245 1457 2000 Email: john-ietf@jck.com