idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-19.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 31, 2016) is 2666 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 (~~), 2 warnings (==), 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 December 31, 2016 6 Expires: July 4, 2017 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-19 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 July 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . 7 75 1.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 7 76 1.2.2. Character Sets and Encodings . . . . . . . . . . . . 9 77 2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 2.1. Namespace Identifier (NID) . . . . . . . . . . . . . . . 10 79 2.2. Namespace Specific String (NSS) . . . . . . . . . . . . . 10 80 2.3. Optional Components . . . . . . . . . . . . . . . . . . . 12 81 2.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 12 82 2.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 13 83 2.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 14 84 3. URN-Equivalence . . . . . . . . . . . . . . . . . . . . . . . 15 85 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 18 89 4.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 4.3. URNs and Relative References . . . . . . . . . . . . . . 19 91 4.4. Transport and Display . . . . . . . . . . . . . . . . . . 19 92 4.5. URI Design and Ownership . . . . . . . . . . . . . . . . 20 93 5. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 20 94 5.1. Formal URN Namespaces . . . . . . . . . . . . . . . . . . 21 95 5.2. Informal URN Namespaces . . . . . . . . . . . . . . . . . 23 97 6. Defining and Registering a URN Namespace . . . . . . . . . . 23 98 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 99 6.2. Registration Policy and Process: Community Registrations 24 100 6.3. Registration Policy and Process: Fast Track for Standards 101 Development Organizations, Scientific Societies, and 102 Similar Bodies . . . . . . . . . . . . . . . . . . . . . 25 103 6.4. Completing the Template . . . . . . . . . . . . . . . . . 26 104 6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 26 105 6.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 27 106 6.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 28 107 6.4.4. Security and Privacy . . . . . . . . . . . . . . . . 28 108 6.4.5. Interoperability . . . . . . . . . . . . . . . . . . 29 109 6.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 29 110 6.4.7. Additional Information . . . . . . . . . . . . . . . 29 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 112 7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 30 113 7.2. Registration of URN Namespaces . . . . . . . . . . . . . 30 114 8. Security and Privacy Considerations . . . . . . . . . . . . . 31 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 117 9.2. Informative References . . . . . . . . . . . . . . . . . 31 118 Appendix A. Registration Template . . . . . . . . . . . . . . . 35 119 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 36 120 B.1. Syntax changes from RFC 2141 . . . . . . . . . . . . . . 36 121 B.2. Other changes from RFC 2141 . . . . . . . . . . . . . . . 36 122 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 37 123 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 37 124 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 37 125 Appendix F. Change log for versions of draft-ietf-urnbis- 126 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 38 127 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 38 128 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 38 129 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 39 130 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 39 131 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 39 132 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 40 133 F.7. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 40 134 F.8. Changes from -15 (2016-02-04) to -16 . . . . . . . . . . 40 135 F.9. Changes from -16 (2016-04-16) to -17 . . . . . . . . . . 41 136 F.10. Changes from -17 (2016-06-27) to -18 . . . . . . . . . . 42 137 F.11. Changes from -18 (2016-09-05) to -19 . . . . . . . . . . 42 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 140 1. Introduction 142 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 143 [RFC3986] that is assigned under the "urn" URI scheme and a 144 particular URN namespace, with the intent that the URN will be a 145 persistent, location-independent resource identifier. A URN 146 namespace is a collection of such URNs, each of which is (1) unique, 147 (2) assigned in a consistent and managed way, and (3) assigned 148 according to a common definition. (Some URN namespaces create names 149 that exist only as URNs, whereas others assign URNs based on names 150 that were already created in non-URN identifier systems, such as 151 ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].) 153 The assignment of URNs is done by an organization (or, in some cases, 154 according to an algorithm or other automated process) that has been 155 formally delegated a URN namespace within the "urn" scheme (e.g., a 156 URN in the 'example' URN namespace [RFC6963] might be of the form 157 "urn:example:foo"). 159 This document rests on two key assumptions: 161 1. Assignment of a URN is a managed process. 163 2. The space of URN namespaces is itself managed. 165 While other URI schemes may allow resource identifiers to be freely 166 chosen and assigned, such is not the case for URNs. The syntactical 167 correctness of a name starting with "urn:" is not sufficient to make 168 it a URN. In order for the name to be a valid URN, the namespace 169 identifier (NID) needs to be registered in accordance with the rules 170 defined here and the remaining parts of the assigned-name portion of 171 the URN need to be generated in accordance with the rules for the 172 registered URN namespace. 174 So that information about both URN syntax and URN namespaces is 175 available in one place, this document does the following: 177 1. Defines the canonical syntax for URNs in general (in a way that 178 is consistent with URI syntax), specifies methods for determining 179 URN-equivalence, and discusses URI conformance. 181 2. Specifies a method for defining a URN namespace and associating 182 it with a namespace identifier (NID), and describes procedures 183 for registering URN NIDs with the Internet Assigned Numbers 184 Authority (IANA). 186 For URN syntax and URN namespaces, this document modernizes and 187 replaces the original specifications for URN syntax [RFC2141] and for 188 the definition and registration of URN namespaces [RFC3406]. These 189 modifications build on the key requirements provided in the original 190 functional description for URNs [RFC1737] and on the lessons of many 191 years of experience. In those original documents and in the present 192 one, the intent is to define URNs in a consistent manner so that, 193 wherever practical, the parsing, handling, and resolution of URNs can 194 be independent of the URN namespace within which a given URN is 195 assigned. 197 Together with input from several key user communities, the history 198 and experiences with URNs dictated expansion of the URN definition to 199 support new functionality, including the use of syntax explicitly 200 reserved for future standardization in RFC 2141. All URN namespaces 201 and URNs that were valid under the earlier specifications remain 202 valid even though it may be useful to update some of them to take 203 advantage of new features. 205 The foregoing considerations, together with various differences 206 between URNs and URIs that are locators (specifically URLs) as well 207 as the greater focus on URLs in RFC 3986 as the ultimate successor to 208 [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 209 and this specification that appear (or perhaps actually are) not 210 completely consistent, especially with regard to actions or semantics 211 other than the basic syntax itself. If such situations arise, 212 discussions of URNs and URN namespaces should be interpreted 213 according to this document and not by extrapolation from RFC 3986. 215 Summaries of changes from RFC 2141 and RFC 3406 appear in Appendix B 216 and Appendix C respectively. This document obsoletes both [RFC2141] 217 and [RFC3406]. While it does not explicitly update or replace 218 [RFC1737] or [RFC2276], the reader who references those documents 219 should be aware that the conceptual model of URNs in this document is 220 slightly different from those older specifications. 222 1.1. Terminology 224 The following terms are distinguished from each other as described 225 below: 227 URN: A URI (as defined in RFC 3986) using the "urn" scheme and with 228 the properties of a "name" as described in that document as well 229 as the properties described in this one. The term applies to the 230 entire URI including its optional components. Note to the reader: 231 the term "URN" has been used in other contexts to refer to a URN 232 namespace, the namespace identifier (NID), the Assigned-name, and 233 to URIs that do not use the "urn" scheme. All but the last of 234 these is described using more specific terminology elsewhere in 235 this document, but, because of those other uses, the term should 236 be used and interpreted with care. 238 Locator: An identifier that provides a means of accessing a 239 resource. 241 Identifier system: A managed collection of names. This document 242 refers to identifier systems outside the context of URNs as "non- 243 URN identifier systems". 245 URN namespace: An identifier system that is associated with a URN 246 namespace identifier (NID). 248 NID: The identifier associated with a URN namespace. 250 NSS: The URN-namespace-specific part of a URN. 252 Assigned-name: The combination of the 'urn:' scheme, the NID, and 253 the NSS. An "Assigned-name" is consequently a substring of a URN 254 (as defined above) if that URN contains any additional components 255 (see Section 2). 257 The term "name" is deliberately not defined here and should be (and 258 in practice, is) used only very informally. RFC 3986 uses the term 259 as a category of URI distinguished from "locator" (Section 1.1.3) but 260 also uses it in other contexts. If those uses are treated as 261 definitions, they conflict with, e.g., the idea of the name of a URN 262 namespace, i.e., a NID or terms associated with non-URN identifier 263 systems. 265 This document uses the terms "resource", "identifier", "identify", 266 "dereference", "representation", and "metadata" roughly as defined in 267 the URI specification [RFC3986]. 269 This document uses the terms "resolution" and "resolver" in roughly 270 the sense in which they were used in the original discussion of 271 architectural principles for URNs [RFC2276], i.e., "resolution" is 272 the act of supplying services related to the identified resource, 273 such as translating the persistent URN into one or more current 274 locators for the resource, delivering metadata about the resource in 275 an appropriate format, or even delivering a representation of the 276 resource (e.g., a document) without requiring further intermediaries. 277 At the time of this writing, resolution services are described in 278 [RFC2483]. 280 On the distinction between representations and metadata, see 281 Section 1.2.2 of [RFC3986]. 283 Several other terms related to "normalization" operations that are 284 not part of the Unicode Standard [UNICODE] are also used here as they 285 are in RFC 3986. 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 289 "OPTIONAL" in this document are to be interpreted as described in 290 [RFC2119]. 292 1.2. Design Tradeoffs 294 To a degree much greater than when URNs were first considered and 295 their uses outlined (see [RFC1737]), issues of persistent identifiers 296 on the Internet involve fundamental design tradeoffs that are much 297 broader than URNs or the URN approach, and even touch on open 298 research questions within the information sciences community. Ideal 299 and comprehensive specifications about what should be done or 300 required across the entire universe of URNs would require general 301 agreement about, and solutions to, a wide range of such issues. 302 Although some of those issues were introduced by the Internet or 303 computer-age approaches to character encodings and data abstraction, 304 others predate the Internet and computer systems by centuries; there 305 is unlikely to be agreement about comprehensive solutions in the near 306 future. 308 Although this specification consequently contains some requirements 309 and flexibility that would not be present in a more perfect world, 310 this has been necessary in order to produce a consensus specification 311 that provides a modernized definition of URNs (the unattractive 312 alternative would have been to not modernize the definition in spite 313 of widespread deployment). 315 The following sub-sections describe two of the relevant issues in 316 greater detail. 318 1.2.1. Resolution 320 One issue that is specific to URNs (as opposed to naming systems in 321 general) is the fairly difficult topic of "resolution", discussed in 322 Section 1.1, Section 2.3.1, Section 6.4.6, and elsewhere below. 324 With traditional Uniform Resource Locators (URLs), i.e., with most 325 URIs that are locators, resolution is relatively straightforward 326 because it is used to determine an access mechanism which in turn is 327 used to dereference the locator by (typically) retrieving a 328 representation of the associated resource, such as a document (see 329 Section 1.2.2 of [RFC3986]). 331 By contrast, resolution for URNs is more flexible and varied. 333 One important case involves the mapping of a URN to one or more 334 locators. In this case, the end result is still a matter of 335 dereferencing the mapped locator(s) to one or more representations. 336 The primary difference here is persistence: even if a mapped locator 337 has changed (e.g., a DNS domain name has changed hands and a URL has 338 not been modified to point to a new location or, in a more extreme 339 and hypothetical case, the DNS is replaced entirely), a URN user will 340 be able to obtain the correct representation (e.g., a document) as 341 long as the resolver has kept its URN-to-locator mappings up to date. 342 Consequently, the relevant relationships can be defined quite 343 precisely for URNs that resolve to locators which in turn are 344 dereferenced to a representation. 346 However, this specification permits several other cases of URN 347 resolution as well as URNs for resources that do not involve 348 information retrieval systems. This is true either individually for 349 particular URNs or (as defined below) collectively for entire URN 350 namespaces. 352 Consider a namespace of URNs that resolve to locators which in turn 353 are dereferenced only to metadata about resources because the 354 underlying systems contain no representations of those resources; an 355 example might be a URN namespace for International Standard Name 356 Identifiers (ISNI) as that identifier system is defined in 357 [ISO.27729.2012], wherein by default a URN would be resolved only to 358 a metadata record describing the individual identified by the ISNI. 360 Consider also URNs that resolve to representations only if the 361 requesting entity is authorized to obtain the representation, whereas 362 other entities can obtain only metadata about the resource; an 363 example might be documents held within the legal depository 364 collection of a national library. 366 Finally, some URNs might not be intended to resolve to locators at 367 all; examples might include URNs identifying XML namespace names 368 (e.g., the 'dgiwg' URN namespace specified by [RFC6288]), URNs 369 identifying application features that can be supported within a 370 communications protocol (e.g., the 'alert' URN namespace specified by 371 [RFC7462]), and URNs identifying enumerated types such as values in a 372 registry (e.g., a URN namespace could be used to individually 373 identify the values in all IANA registries, as provisionally proposed 374 in [I-D.saintandre-iana-urn]). 376 Various types of URNs and multiple resolution services which may be 377 available for them leave the concept of "resolution" more complicated 378 but also much richer for URNs than the straightforward case of 379 resolution to a locator that is dereferenced to a representation. 381 1.2.2. Character Sets and Encodings 383 A similar set of considations apply to character sets and encodings. 384 URNs, especially URNs that will be used as user-facing identifiers, 385 should be convenient to use in local languages and writing systems, 386 easily specified with a wide range of keyboards and local 387 conventions, and unambiguous. There are tradeoffs among those goals 388 and it is impossible at present to see how a simple and readily- 389 understandable set of rules could be developed that would be optimal, 390 or even reasonable, for all URNs. The discussion in Section 2.2 391 defines an overall framework that should make generalized parsing and 392 processing possible, but also makes recommendations about rules for 393 individual URN namespaces. 395 2. URN Syntax 397 As discussed above, the syntax for URNs in this specification allows 398 significantly more functionality than was the case in the earlier 399 specifications, most recently [RFC2141]. It is also harmonized with 400 the general URI syntax [RFC3986] (which, it must be noted, was 401 completed after the earlier URN specifications). 403 However, this specification does not extend the URN syntax to allow 404 direct use of characters outside the ASCII range [RFC20]. That 405 restriction implies that any such characters need to be percent- 406 encoded as described in Section 2.1 of the URI specification 407 [RFC3986]. 409 The basic syntax for a URN is defined using the Augmented Backus-Naur 410 Form (ABNF) as specified in [RFC5234]. Rules not defined here 411 (specifically: alphanum, fragment, and pchar) are defined as part of 412 the URI syntax [RFC3986] and used here to point out the syntactic 413 relationship with the terms used there. The definitions of some of 414 the terms used below are not comprehensive; additional restrictions 415 are imposed by the prose that can be found in sections of this 416 document that are specific to those terms (especially r-component in 417 Section 2.3.1 and q-component in Section 2.3.2). 419 namestring = assigned-name 420 [ rq-components ] 421 [ "#" f-component ] 422 assigned-name = "urn" ":" NID ":" NSS 423 NID = (alphanum) 0*30(ldh) (alphanum) 424 ldh = alphanum / "-" 425 NSS = pchar *(pchar / "/") 426 rq-components = [ "?+" r-component ] 427 [ "?=" q-component ] 428 r-component = pchar *( pchar / "/" / "?" ) 429 q-component = pchar *( pchar / "/" / "?" ) 430 f-component = fragment 432 The question mark character "?" can be used without percent-encoding 433 inside r-components, q-components, and f-components. Other than 434 inside those components a "?" that is not immediately followed by "=" 435 or "+" is not defined for URNs and SHOULD be treated as a syntax 436 error by URN-specific parsers and other processors. 438 The following sections provide additional information about the 439 syntactic elements of URNs. 441 2.1. Namespace Identifier (NID) 443 Namespace identifiers (NIDs) are case insensitive (e.g., "ISBN" and 444 "isbn" are equivalent). 446 Characters outside the ASCII range [RFC20] are not permitted in NIDs, 447 and no encoding mechanism for such characters is supported. 449 Section 5.1 and Section 5.2 impose additional constraints on the 450 strings that can be used as NIDs, i.e., the syntax shown above is not 451 comprehensive. 453 2.2. Namespace Specific String (NSS) 455 The namespace specific string (NSS) is a string, unique within a URN 456 namespace, that is assigned and managed in a consistent way and that 457 conforms to the definition of the relevant URN namespace. The 458 combination of the NID (unique across the entire "urn" scheme) and 459 the NSS (unique within the URN namespace) ensures that the resulting 460 URN is globally unique. 462 The NSS as specified in this document allows several characters not 463 permitted by earlier specifications (see Appendix B). In particular, 464 the "/" character, which is now allowed, effectively makes it 465 possible to encapsulate hierarchical names from non-URN identifier 466 systems. For instance, consider the hypothetical example of a 467 hierarchical identifier system in which the names take the form of a 468 sequence of numbers separated by the "/" character, such as 469 "1/406/47452/2". If the authority for such names were to use URNs, 470 it would be natural to place the existing name in the NSS, resulting 471 in URNs such as "urn:example:1/406/47452/2". 473 Those changes to the syntax for the NSS do not modify the encoding 474 rules for URN namespaces that were defined in accordance with 475 [RFC2141]. If any such URN namespace whose names are used outside of 476 the URN context (i.e., in a non-URN identifier system) also allows 477 the use of "/", "~", or "&" in the native form within that identifier 478 system, then the encoding rules for that URN namespace are not 479 changed by this specification. 481 Depending on the rules governing a non-URN identifier system and its 482 associated URN namespace, names that are valid in that identifier 483 system might contain characters that are not allowed by the "pchar" 484 production referenced above (e.g., characters outside the ASCII range 485 or, consistent with the restrictions in RFC 3986, the characters "/", 486 "?", "#", "[", and "]"). While such a name might be valid within the 487 non-URN identifier system, it is not a valid URN until it has been 488 translated into an NSS that conforms to the rules of that particular 489 URN namespace. In the case of URNs that are formed from names that 490 exist separately in a non-URN identifier system, translation of a 491 name from its "native" format to URN format is accomplished by using 492 the canonicalization and encoding methods defined for URNs in general 493 or specific rules for that URN namespace. Software that is not aware 494 of namespace-specific canonicalization and encoding rules MUST NOT 495 construct URNs from the name in the non-URN identifier system. 497 In particular, with regard to characters outside the ASCII range, 498 URNs that appear in protocols or that are passed between systems MUST 499 use only Unicode characters encoded in UTF-8 and further encoded as 500 required by RFC 3986. To the extent feasible consistent with the 501 requirements of names defined and standardized elsewhere, as well as 502 the principles discussed in Section 1.2, the characters used to 503 represent names SHOULD be restricted to either ASCII letters and 504 digits or to the characters and syntax of some widely-used model such 505 as those of IDNA [RFC5890], PRECIS [RFC7613], or the Unicode 506 Identifier and Pattern Syntax specification [UAX31]. 508 In order to make URNs as stable and persistent as possible when 509 protocols evolve and the environment around them changes, URN 510 namespaces SHOULD NOT allow characters outside the basic Latin 511 repertoire [RFC20] unless the nature of the particular URN namespace 512 makes such characters necessary. 514 2.3. Optional Components 516 This specification includes three optional components in the URN 517 syntax. They are known as r-component, q-component, and f-component 518 and are described in more detail below. Because this specification 519 focuses almost exclusively on URN syntax, it does not define detailed 520 semantics of these components for URNs in general. However, each of 521 these components has a distinct role that is independent of any given 522 URN and its URN namespace. It is intended that clients will be able 523 to handle these components uniformly for all URNs. These components 524 MAY be used with URNs from existing URN namespaces, whether or not a 525 URN namespace explicitly supports them. However, consistent with the 526 approach taken in RFC 3986, the behavior of a URN that contains 527 components that are undefined or meaningless for a particular URN 528 namespace or resource is not defined. The following sections 529 describe these optional components and their interpretation in 530 greater detail. 532 2.3.1. r-component 534 The r-component is intended for passing parameters to URN resolution 535 services (taken broadly, see Section 1.2) and interpreted by those 536 services. (By contrast, passing parameters to the resources 537 identified by a URN, or to applications that manage such resources, 538 is handled by q-components as described in the next section.) 540 The URN r-component has no syntactic counterpart in any other known 541 URI scheme. 543 The sequence "?+" introduces the r-component. The r-component ends 544 with a "?=" sequence (which begins a q-component) or a "#" character 545 (number sign, which begins an f-component). If neither of those 546 appear, the r-component continues to the end of the URN. Note that 547 characters outside the ASCII range [RFC20] MUST be percent-encoded 548 using the method defined in Section 2.1 of the generic URI 549 specification [RFC3986]. 551 As described under Section 3, the r-component SHALL NOT be taken into 552 account when determining URN-equivalence. However, the r-component 553 SHALL be supplied along with the URN when presenting a request to a 554 URN resolution service. 556 This document defines only the syntax of the r-component and reserves 557 it for future use. The exact semantics of the r-component and its 558 use in URN resolution protocols are a matter for potential 559 standardization in separate specifications, presumably including 560 specifications that define conventions and a registry for resolution 561 service identifiers. 563 Consider the hypothetical example of passing parameters to a 564 resolution service (say, an ISO alpha-2 country code [ISO.3166-1] in 565 order to select the preferred country in which to search for a 566 physical copy of a book). This could perhaps be accomplished by 567 specifying the country code in the r-component, resulting in URNs 568 such as: 570 urn:example:foo-bar-baz-qux?+CCResolve:cc=uk 572 While the above should serve as a general explanation and 573 illustration of the intent for r-components, there are many open 574 issues with them, including their relationship to resolution 575 mechanisms associated with the particular URN namespace at 576 registration time. Thus r-components SHOULD NOT be used for actual 577 URNs until additional development and standardization work is 578 complete, including specification of any necessary registration 579 mechanisms. 581 2.3.2. q-component 583 The q-component is intended for passing parameters to either the 584 named resource or a system that can supply the requested service, for 585 interpretation by that resource or system. (By contrast, passing 586 parameters to URN resolution services is handled by r-components as 587 described in the previous section.) 589 The URN q-component has the same syntax as the URI query component, 590 but is introduced by "?=", not "?" alone. For a URN that may be 591 resolved to a URI that is a locator, the semantics of the q-component 592 are identical to those for the query component of that URI. Thus URN 593 resolvers returning a URI that is a locator for a URN with a 594 q-component do this by copying the q-component from the URN to the 595 query component of the URI. An example of the copying operation 596 appears below. 598 This specification does not specify a required behavior in the case 599 of URN resolution to a URI that is a locator when the original URN 600 has a q-component and the URI has a query string. Different 601 circumstance may require different approaches. Resolvers SHOULD 602 document their strategy in such cases. 604 If the URN does not resolve to a URI that is a locator, the 605 interpretation of the q-component is undefined by this specification. 606 For URNs which may be resolved to a URI that is a locator, the 607 semantics of the q-component are identical to those for queries to 608 the resource located via that URI. 610 For the sake of consistency with RFC 3986, the general syntax and the 611 semantics of q-components are not defined by, or dependent on, the 612 URN namespace of the URN. In parallel with RFC 3896, specifics of 613 syntax and semantics, e.g., which keywords or terms are meaningful, 614 of course may depend on a particular URN namespace or even a 615 particular resource. 617 The sequence "?=" introduces the q-component. The q-component 618 terminates when a "#" character (number sign, which begins an 619 f-component) appears. If that character does not appear, the 620 q-component continues to the end of the URN. The characters slash 621 ("/") and question mark ("?") may represent data within the 622 q-component. Note that characters outside the ASCII range [RFC20] 623 MUST be percent-encoded using the method defined in Section 2.1 of 624 the generic URI specification [RFC3986]. 626 As described in Section 3, the q-component SHALL NOT be taken into 627 account when determining URN-equivalence. 629 URN namespaces and associated information placement in syntax SHOULD 630 be designed to avoid any need for a resolution service to consider 631 the q-component. Namespace-specific and more generic resolution 632 systems MUST NOT require that q-component information be passed to 633 them for processing. 635 Consider the hypothetical example of passing parameters to an 636 application that returns weather reports from different regions or 637 for different time periods. This could perhaps be accomplished by 638 specifying latitude and longitude coordinates and datetimes in the 639 URN's q-component, resulting in URNs such as the following. 641 urn:example:weather?=op=map&lat=39.56 642 &lon=-104.85&datetime=1969-07-21T02:56:15Z 644 If this example resolved to an HTTP URI, the result might look like: 646 https://weatherapp.example?op=map&lat=39.56 647 &lon=-104.85&datetime=1969-07-21T02:56:15Z 649 2.3.3. f-component 651 The f-component is intended to be interpreted by the client as a 652 specification for a location within, or region of, the named 653 resource. It distinguishes the constituent parts of a resource named 654 by a URN. For a URN that resolves to one or more locators which can 655 be dereferenced to a representation, or where the URN resolver 656 directly returns a representation of the resource, the semantics of 657 an f-component are defined by the media type of the representation. 659 The URN f-component has the same syntax as the URI fragment 660 component. If a URN containing an f-component resolves to a single 661 URI that is a locator associated with the named resource, the 662 f-component from the URN can be applied (usually by the client) as 663 the fragment of that URI. If the URN does not resolve to a URI that 664 is a locator, the interpretation of the f-component is undefined by 665 this specification. Thus, for URNs which may be resolved to a URI 666 that is a locator, the semantics of f-components are identical to 667 those of fragments for that resource. 669 For the sake of consistency with RFC 3986, neither the general syntax 670 nor the semantics of f-components are defined by, or dependent on, 671 the URN namespace of the URN. In parallel with RFC 3896, specifics 672 of syntax and semantics, e.g., which keywords or terms are 673 meaningful, of course may depend on a particular URN namespace or 674 even a particular resource. 676 The f-component is introduced by the number sign ("#") character and 677 terminated by the end of the URI. Any characters outside the ASCII 678 range [RFC20] that appear in the f-component MUST be percent-encoded 679 using the method defined in Section 2.1 of the generic URI 680 specification [RFC3986]. 682 As described under Section 3, the f-component SHALL NOT be taken into 683 account when determining URN-equivalence. 685 Clients SHOULD NOT pass f-components to resolution services unless 686 those services also perform object retrieval and interpretation 687 functions. 689 Consider the hypothetical example of obtaining resources that are 690 part of a larger entity (say, the chapters of a book). Each part 691 could be specified in the f-component, resulting in URNs such as: 693 urn:example:foo-bar-baz-qux#somepart 695 3. URN-Equivalence 697 3.1. Procedure 699 For various purposes such as caching, it is often desirable to 700 determine if two URNs are "the same". This is done most generally 701 (i.e., independent of the scheme) by testing for equivalence (see 702 Section 6.1 of [RFC3986]). 704 The generic URI specification [RFC3986] is very flexible about 705 equality comparisons, putting the focus on allowing false negatives 706 and avoiding false positives. If comparisons are made in a scheme- 707 independent way, i.e., as URI comparisons only, many URNs that this 708 specification considers equal would be rejected. The discussion 709 below applies when the URIs involved are known to be URNs, and thus 710 uses the terms "URN-equivalent" and "URN-equivalence" to refer to 711 equivalence as specified in this document. 713 Two URNs are URN-equivalent if their portions are 714 octet-by-octet equal after applying case normalization (as specified 715 in Section 6.2.2.1 of [RFC3986]) to the following constructs: 717 1. the URI scheme "urn", by conversion to lower case 719 2. the NID, by conversion to lower case 721 3. any percent-encoded characters in the NSS (that is, all character 722 triplets that match the production found in 723 Section 2.1 of the base URI specification [RFC3986]), by 724 conversion to upper case for the digits A-F. 726 Percent-encoded characters MUST NOT be decoded, i.e., percent- 727 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 728 MUST NOT be applied as part of the comparison process. 730 If an r-component, q-component, or f-component (or any combination 731 thereof) is included in a URN, it MUST be ignored for purposes of 732 determining URN-equivalence. 734 URN namespace definitions MAY include additional rules for URN- 735 equivalence, such as case-insensitivity of the NSS (or parts 736 thereof). Such rules MUST always have the effect of eliminating some 737 of the false negatives obtained by the procedure above and MUST NOT 738 result in treating two URNs as not "the same" if the procedure here 739 says they are URN-equivalent. For related considerations with regard 740 to NID registration, see below. 742 3.2. Examples 744 This section shows a variety of URNs (using the "example" NID defined 745 in [RFC6963]) that highlight the URN-equivalence rules. 747 First, because the scheme and NID are case-insensitive, the following 748 three URNs are URN-equivalent to each other: 750 o urn:example:a123,z456 752 o URN:example:a123,z456 754 o urn:EXAMPLE:a123,z456 756 Second, because the r-component, q-component, and f-component are not 757 taken into account for purposes of testing URN-equivalence, the 758 following three URNs are URN-equivalent to the first three examples 759 above: 761 o urn:example:a123,z456?+abc 763 o urn:example:a123,z456?=xyz 765 o urn:example:a123,z456#789 767 Third, because the "/" character (and anything that follows it) in 768 the NSS is taken into account for purposes of URN-equivalence, the 769 following URNs are not URN-equivalent to each other or to the six 770 preceding URNs: 772 o urn:example:a123,z456/foo 774 o urn:example:a123,z456/bar 776 o urn:example:a123,z456/baz 778 Fourth, because of percent-encoding, the following URNs are URN- 779 equivalent only to each other and not to any of those above (note 780 that, although %2C is the percent-encoded transformation of "," from 781 the previous examples, such sequences are not decoded for purposes of 782 testing URN-equivalence): 784 o urn:example:a123%2Cz456 786 o URN:EXAMPLE:a123%2cz456 788 Fifth, because characters in the NSS other than percent-encoded 789 sequences are treated in a case-sensitive manner (unless otherwise 790 specified for the URN namespace in question), the following URNs are 791 not URN-equivalent to the first three URNs: 793 o urn:example:A123,z456 795 o urn:example:a123,Z456 796 Sixth, on casual visual inspection of a URN presented in a human- 797 oriented interface the following URN might appear the same as the 798 first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be 799 confused with U+0061 LATIN SMALL LETTER A), but it is not URN- 800 equivalent to the first three URNs: 802 o urn:example:%D0%B0123,z456 804 4. URI Conformance 806 4.1. Use in URI Protocol Slots 808 Because a URN is, syntactically, a URI under the "urn" scheme, in 809 theory a URN can be placed in any protocol slot that allows for a URI 810 (to name just a few, the 'href' and 'src' attributes in HTML, the 811 element in HTML, the 'xml:base' attribute in XML [XML-BASE], 812 and the 'xmlns' attribute in XML for XML namespace names 813 [XML-NAMES]). 815 However, this does not imply that, semantically, it always makes 816 sense in practice to place a URN in a given URI protocol slot; in 817 particular, because a URN might not specify the location of a 818 resource or even point indirectly to one, it might not be appropriate 819 to place a URN in a URI protocol slot that points to a resource 820 (e.g., the aforementioned 'href' and 'src' attributes). 822 Ultimately, guidelines regarding when it is appropriate to use URIs 823 under the "urn" scheme (or any other scheme) are the responsibility 824 of specifications for individual URI protocol slots (e.g., the 825 specification for the 'xml:base' attribute in XML might recommend 826 that it is inappropriate to use URNs in that protocol slot). This 827 specification cannot possibly anticipate all of the relevant cases, 828 and it is not the place of this specification to require or restrict 829 usage for individual protocol slots. 831 4.2. Parsing 833 In part because of the separation of URN semantics from more general 834 URI syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors 835 need to pay special attention to the parsing and analysis rules of 836 RFC 3986 and, in particular, must treat the URI as opaque unless the 837 scheme and its requirements are recognized. In the latter case, such 838 processors may be in a position to invoke scheme-appropriate 839 processing, e.g., by a URN resolver. A URN resolver can either be an 840 external resolver that the URI resolver knows of, or it can be 841 functionality built into the URI resolver. Note that this 842 requirement might impose constraints on the contexts in which URNs 843 are appropriately used; see Section 4.1. 845 4.3. URNs and Relative References 847 Section 5.2 of [RFC3986] describes an algorithm for converting a URI 848 reference that might be relative to a given base URI into "parsed 849 components" of the target of that reference, which can then be 850 recomposed per RFC 3986 Section 5.3 into a target URI. This 851 algorithm is problematic for URNs because their syntax does not 852 support the necessary path components. However, if the algorithm is 853 applied independent of a particular scheme, it should work 854 predictably for URNs as well, with the following understandings 855 (syntax production terminology taken from RFC 3986): 857 1. A system that encounters a that obeys the syntax 858 for , whether it explicitly has the scheme "urn" or 859 not, will convert it into a target URI as specified in RFC 3986. 861 2. Because of the persistence and stability expectations of URNs, 862 authors of documents, etc., that utilize URNs should generally 863 avoid the use of the "urn" scheme in any that is 864 not strictly a as specified in RFC 3986, specifically 865 including those that would require processing of . 867 4.4. Transport and Display 869 When URNs are transported and exchanged, they MUST be represented in 870 the format defined herein. Further, all URN-aware applications MUST 871 offer the option of displaying URNs in this canonical form to allow 872 for direct transcription (for example by copy-and-paste techniques). 873 Such applications might support display of URNs in a more human- 874 friendly form and might use a character set that includes characters 875 that are not permitted in URN syntax as defined in this specification 876 (e.g., when displaying URNs to humans, such applications might 877 replace percent-encoded strings with characters from an extended 878 character repertoire such as Unicode [UNICODE]). 880 To minimize user confusion, any application displaying URIs SHOULD 881 display the complete URI (including, for URNs, the "urn" scheme and 882 any components) to ensure that there is no confusion between URN NIDs 883 and URI scheme identifiers. For example, a URI beginning with 884 "urn:xmpp:" [RFC4854] is very different from a URI beginning with 885 "xmpp:" [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] 886 is different from, and possibly completely unrelated to, a possible 887 DOI URN namespace. 889 4.5. URI Design and Ownership 891 As mentioned, the assignment of URNs within a URN namespace is a 892 managed process, as is the assignment of URN namespaces themselves. 893 Although design of the URNs to be assigned within a given URN 894 namespace is ceded by this specification to the URN namespace 895 manager, doing so in a managed way avoids the problems inherent in 896 unmanaged generation of URIs as described in the recommendations 897 regarding URI design and ownership [RFC7320]. 899 5. URN Namespaces 901 A URN namespace is a collection of names that obey three constraints: 902 each name is (1) unique, (2) assigned in a consistent way, and (3) 903 assigned according to a common definition. 905 1. The "uniqueness" constraint means that a name within the URN 906 namespace is never assigned to more than one resource and never 907 reassigned to a different resource (for the kind of "resource" 908 identified by URNs assigned within the URN namespace). This 909 holds true even if the name itself is deprecated or becomes 910 obsolete. 912 2. The "consistent assignment" constraint means that a name within 913 the URN namespace is assigned by an organization or created in 914 accordance with a process or algorithm that is always followed. 916 3. The "common definition" constraint means that there are clear 917 definitions for the syntax of names within the URN namespace and 918 for the process of assigning or creating them. 920 A URN namespace is identified by a particular NID in order to ensure 921 the global uniqueness of URNs and, optionally, to provide a cue 922 regarding the structure of URNs assigned within a URN namespace. 924 With regard to global uniqueness, using different NIDs for different 925 collections of names ensures that no two URNs will be the same for 926 different resources, because each collection is required to uniquely 927 assign each name. However, a single resource MAY have more than one 928 URN assigned to it, either in the same URN namespace (if the URN 929 namespace permits it) or in different URN namespaces, and either for 930 similar purposes or different purposes. (For example, if a publisher 931 assigns an ISBN [RFC3187] to an electronic publication and that 932 publication is later incorporated into a digital long-term archive 933 operated by a national library, the library might assign the 934 publication an NBN [RFC3188], resulting in two URNs referring to the 935 same book.) Subject to other constraints, such as those imposed by 936 the URI syntax [RFC3986], the rules of the URN scheme are intended to 937 allow preserving the normal and natural form of names specified in 938 non-URN identifier systems when they are treated as URNs. 940 With regard to the structure of names assigned within a URN 941 namespace, the development of a naming structure (and thereby a 942 collection of names) depends on the requirements of the community 943 defining the names, how the names will be assigned and used, etc. 944 These issues are beyond the scope of URN syntax and the general rules 945 for URN namespaces, because they are specific to the community 946 defining a non-URN identifier system or a particular URN namespace 947 (e.g., the bibliographic and publishing communities in the case of 948 the 'ISBN' URN namespace [RFC3187] and the 'ISSN' URN namespace 949 [RFC3044], or the developers of extensions to the Extensible 950 Messaging and Presence Protocol [RFC6120] in the case of the 'XMPP' 951 URN namespace [RFC4854]). 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 1280 [RFC3986] and as discussed in Section 1.2.2 of this 1281 specification. 1283 5. Any special considerations for the meaning of q-components (e.g., 1284 keywords) or f-components (e.g., predefined terms) in the context 1285 of this URN namespace. 1287 6.4.3. Assignment 1289 The "Assignment" section of the template describes matters such as: 1291 1. Mechanisms or authorities for assigning URNs to resources. It 1292 ought to make clear whether assignment is completely open (e.g., 1293 following a particular procedure such as first-come, first-served 1294 (FCFS)), completely closed (e.g., for a private organization), or 1295 limited in various ways (e.g., delegated to authorities 1296 recognized by a particular organization); if limited, it ought to 1297 explain how to become an assigner of names or how to request 1298 assignment of names from existing assignment authorities. 1300 2. Methods for ensuring that URNs within the URN namespace are 1301 unique. For example, names might be assigned sequentially or in 1302 accordance with some well-defined process by a single authority, 1303 assignment might be partitioned among delegated authorities that 1304 are individually responsible for respecting uniqueness rules, or 1305 URNs might be created independently following an algorithm that 1306 itself guarantees uniqueness. 1308 6.4.4. Security and Privacy 1310 The "Security and Privacy" section of the template describes any 1311 potential issues related to security and privacy with regard to 1312 assignment, use, and resolution of names within the URN namespace. 1313 Examples of such issues include: 1315 o The consequences of producing false negatives and false positives 1316 during comparison for URN-equivalence (see Section 1.2.2 of this 1317 specification and "Issues in Identifier Comparison for Security 1318 Purposes" [RFC6943]). 1320 o Leakage of private information when names are communicated on the 1321 public Internet. 1323 o The potential for directory harvesting. 1325 o Various issues discussed in the guidelines for security 1326 considerations in RFCs [RFC3552] and the privacy considerations 1327 for Internet protocols [RFC6973]. 1329 6.4.5. Interoperability 1331 The "Interoperability" section MUST specify any known potential 1332 issues related to interoperability. Examples include possible 1333 confusion with other URN namespaces, non-URN identifier systems, or 1334 URI schemes because of syntax (e.g., percent-encoding of certain 1335 characters) or scope (e.g., overlapping areas of interest). If at 1336 all possible, concerns that arise during the registration of a URN 1337 namespace (e.g., due to the syntax or scope of a non-URN identifier 1338 system) should be resolved as part of or in parallel to the 1339 registration process. 1341 6.4.6. Resolution 1343 The "Resolution" section MUST specify whether resolution mechanisms 1344 are intended or anticipated for URNs assigned within the URN 1345 namespace. 1347 If resolution is intended, then this section SHOULD specify whether 1348 the organization that assigns URNs within the URN namespace intends 1349 to operate or recommend any resolution services for URNs within that 1350 URN namespace. In addition, if the assigning organization intends to 1351 implement registration for publicly advertised resolution services 1352 (for example using a system based on principles similar to those 1353 described in [RFC2276] and [RFC2483]), then this section SHOULD list 1354 or reference the requirements for being publicly advertised by the 1355 assigning organization. In addition, this section SHOULD describe 1356 any special considerations for the handling of r-components in the 1357 context of this URN namespace. 1359 6.4.7. Additional Information 1361 The "Additional Information" section includes information that would 1362 be useful to those trying to understand this registration or its 1363 relationship to other registrations, such as comparisons to existing 1364 URN namespaces that might seem to overlap. 1366 This section of the template is optional. 1368 7. IANA Considerations 1370 7.1. URI Scheme 1372 This section updates the registration of the 'urn' URI scheme in the 1373 Permanent URI Registry [URI-Registry]. 1375 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 1376 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.ietf-urnbis-semantics-clarif] 1458 Klensin, J., "URN Semantics Clarification", draft-ietf- 1459 urnbis-semantics-clarif-04 (work in progress), June 2016. 1461 [I-D.saintandre-iana-urn] 1462 Saint-Andre, P. and M. Cotton, "A Uniform Resource Name 1463 (URN) Namespace for IANA Registries", draft-saintandre- 1464 iana-urn-01 (work in progress), February 2013. 1466 [ISO.27729.2012] 1467 Technical Committee ISO/TC 46, Information and 1468 documentation, Subcommittee SC 9, Identification and 1469 description., "Information and documentation - 1470 International standard name identifier (ISNI)", ISO Draft 1471 Standard 27729, 03 2012. 1473 [ISO.3166-1] 1474 ISO, "Codes for the representation of names of countries 1475 and their subdivisions -- Part 1: Country codes", 1476 ISO 3166-1:2013, 2013. 1478 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1479 Uniform Resource Names", RFC 1737, December 1994. 1481 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1482 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 1483 December 1994, . 1485 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", 1486 RFC 1808, DOI 10.17487/RFC1808, June 1995, 1487 . 1489 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1491 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1492 Name Resolution", RFC 2276, January 1998. 1494 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1495 Necessary for URN Resolution", RFC 2483, January 1999. 1497 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1498 DOI 10.17487/RFC2648, August 1999, 1499 . 1501 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1502 Standard Number) as URN (Uniform Resource Names) within an 1503 ISSN-URN Namespace", RFC 3044, January 2001. 1505 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1506 Book Numbers as Uniform Resource Names", RFC 3187, October 1507 2001. 1509 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 1510 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 1511 October 2001, . 1513 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1514 "Uniform Resource Names (URN) Namespace Definition 1515 Mechanisms", BCP 66, RFC 3406, October 2002. 1517 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1518 Text on Security Considerations", BCP 72, RFC 3552, July 1519 2003. 1521 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1522 for Extensions to the Extensible Messaging and Presence 1523 Protocol (XMPP)", RFC 4854, April 2007. 1525 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1526 (IRIs) and Uniform Resource Identifiers (URIs) for the 1527 Extensible Messaging and Presence Protocol (XMPP)", 1528 RFC 5122, February 2008. 1530 [RFC5890] Klensin, J., "Internationalized Domain Names for 1531 Applications (IDNA): Definitions and Document Framework", 1532 RFC 5890, August 2010. 1534 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1535 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1536 March 2011, . 1538 [RFC6288] Reed, C., "URN Namespace for the Defence Geospatial 1539 Information Working Group (DGIWG)", RFC 6288, 1540 DOI 10.17487/RFC6288, August 2011, 1541 . 1543 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1544 "Deprecating the "X-" Prefix and Similar Constructs in 1545 Application Protocols", BCP 178, RFC 6648, June 2012. 1547 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1548 Specifications and Registration Procedures", BCP 13, 1549 RFC 6838, January 2013. 1551 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1552 Purposes", RFC 6943, May 2013. 1554 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1555 for Examples", BCP 183, RFC 6963, May 2013. 1557 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1558 Morris, J., Hansen, M., and R. Smith, "Privacy 1559 Considerations for Internet Protocols", RFC 6973, July 1560 2013. 1562 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 1563 RFC 7282, June 2014. 1565 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1566 RFC 7320, July 2014. 1568 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 1569 P. Kyzivat, "URNs for the Alert-Info Header Field of the 1570 Session Initiation Protocol (SIP)", RFC 7462, 1571 DOI 10.17487/RFC7462, March 2015, 1572 . 1574 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1575 Enforcement, and Comparison of Internationalized Strings 1576 Representing Usernames and Passwords", RFC 7613, 1577 DOI 10.17487/RFC7613, August 2015, 1578 . 1580 [UAX31] The Unicode Consortium, "Unicode Standard Annex #31: 1581 Unicode Identifier and Pattern Syntax", June 2015, 1582 . 1584 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015, 1585 . 1587 [URI-Registry] 1588 IANA, "Permanent URI Schemes", 1589 . 1592 [XML-BASE] 1593 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1594 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1595 January 2009, 1596 . 1598 [XML-NAMES] 1599 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1600 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1601 Web Consortium Recommendation REC-xml-names-20091208, 1602 December 2009, 1603 . 1605 Appendix A. Registration Template 1607 Namespace ID: Requested of IANA (formal) or assigned by IANA 1608 (informal). 1610 Version: The version of the registration, starting with 1 and 1611 incrementing by 1 with each new version. 1613 Date: The date when the registration is requested of IANA, using the 1614 format YYYY-MM-DD. 1616 Registrant: The person or organization that has registered the NID, 1617 including the name and address of the registering organization, as 1618 well as the name and contact information (email, phone number, or 1619 postal address) of the designated contact person. If the 1620 registrant is a recognized standards development organization, 1621 scientific society, or similar body requesting the fast track 1622 registration procedure (see Section 6.3), that information should 1623 be clearly indicated in this section of the template. 1625 Purpose: Described under Section 6.4.1 of this document. 1627 Syntax: Described under Section 6.4.2 of this document. Unless the 1628 registration explicitly describes the semantics of r-components, 1629 q-components, and f-components in the context of this URN 1630 namespace, those semantics are undefined. 1632 Assignment: Described under Section 6.4.3 of this document. 1634 Security and Privacy: Described under Section 6.4.4 of this 1635 document. 1637 Interoperability: Described under Section 6.4.5 of this document. 1639 Resolution: Described under Section 6.4.6 of this document. 1641 Documentation: A pointer to an RFC, a specification published by 1642 another standards development organization, or another stable 1643 document that provides further information about this URN 1644 namespace. 1646 Additional Information: Described under Section 6.4.7 of this 1647 document. 1649 Revision Information: Description of changes from prior version(s). 1650 (Applicable only when earlier registrations have been revised.) 1652 Appendix B. Changes from RFC 2141 1654 This document makes substantive changes from the syntax and semantics 1655 of [RFC2141]: 1657 B.1. Syntax changes from RFC 2141 1659 The syntax of URNs as provided in [RFC2141] was defined before the 1660 updated specification of URIs in [RFC3986]. The definition of URN 1661 syntax is updated in this document to do the following: 1663 o Ensure consistency with the URI syntax. 1665 o Facilitate the use of URNs with parameters similar to URI queries 1666 and fragments. 1668 o Permit parameters influencing URN resolution. 1670 o Ease the use of URNs with non-URN identifier systems that include 1671 the '/' character. 1673 In particular, this specification does the following: 1675 o Extends URN syntax to explicitly allow the characters '/', "?", 1676 and "#", which were reserved for future use by RFC 2141. This 1677 change effectively also allows several components of the URI 1678 syntax although without necessarily tying those components to URI 1679 semantics. 1681 o Defines general syntax for an additional component that can be 1682 used in interactions with a URN resolution service. 1684 o Disallows "-" at the end of a NID. 1686 o Allows the "/", "~", and "&" characters in the namespace-specific 1687 string (NSS). 1689 o Makes several smaller syntax adjustments. 1691 B.2. Other changes from RFC 2141 1693 o Formally registers 'urn' as a URI scheme. 1695 o Allows what are now called r-components, q-components, and 1696 f-components. 1698 In addition, some of the text has been updated to be consistent with 1699 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1700 the processes for registering information with the IANA [RFC5226], as 1701 well as more modern guidance with regard to security [RFC3552], 1702 privacy [RFC6973], and identifier comparison [RFC6943]. 1704 Appendix C. Changes from RFC 3406 1706 This document makes the following substantive changes from [RFC3406]: 1708 1. Relaxes the registration policy for formal URN namespaces from 1709 "IETF Review" to "Expert Review" as discussed in Section 6.2. 1711 2. Removes the category of experimental URN namespaces, consistent 1712 with [RFC6648]. Experimental URN namespaces were denoted by 1713 prefixing the namespace identifier with the string "X-". Because 1714 experimental URN namespaces were never registered, removing the 1715 experimental category has no impact on the existing registries. 1716 Because experimental URN namespaces are not managed, strings 1717 conforming to URN syntax within experimental URN namespaces are 1718 not valid URNs. Truly experimental usages MAY, of course, employ 1719 the 'example' namespace [RFC6963]. 1721 3. Adds some information to, but generally simplifies, the URN 1722 namespace registration template. 1724 Appendix D. Contributors 1726 RFC 2141, which provided the basis for the syntax portion of this 1727 document, was authored by Ryan Moats. 1729 RFC 3406, which provided the basis for the namespace portion of this 1730 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1731 Renato Iannella, and Patrik Faltstrom. 1733 Their work is gratefully acknowledged. 1735 Appendix E. Acknowledgements 1737 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1738 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1739 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1740 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1741 participants in the URNBIS WG for their input. Alfred Hoenes in 1742 particular edited an earlier version of this document and served as 1743 co-chair of the URNBIS WG. 1745 Juha Hakala deserves special recognition for his dedication to 1746 successfully completing this work, as do Andrew Newton and Melinda 1747 Shore in their roles as working group co-chairs and Barry Leiba in 1748 his role as area director and then as co-chair. 1750 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1752 [[RFC Editor: please remove this appendix before publication.]] 1754 F.1. Changes from -08 to -09 1756 o Altered the text in Section 4 to reflect list discussions about 1757 the earlier phrasing. Also added DOI example and citation to that 1758 section. 1760 o Clarified the naming rules for formal namespaces and their 1761 relationship to ISO 3166, IDNA, etc., reserved strings. 1763 o Added an explicit statement about use of URNs in various protocols 1764 and contexts to Section 4. 1766 o Clarified that experimental namespace NIDs, which were explicitly 1767 not registered, are not valid URNs (in Section 5. 1769 o Transformed the partial production in Section 5.2 into valid ABNF. 1771 o Added more text about p-/q-/f-components and recommendations about 1772 use. 1774 o Added clarifying note about "?" within q-components and 1775 f-components. 1777 o Added explicit requirement that revisions of existing 1778 registrations document the changes and added a slot for that 1779 description to the template. 1781 o Many small editorial changes and adjustments including adding 1782 additional references and cross-references for clarification. 1784 o Inserted a placeholder for additional examples. 1786 F.2. Changes from -09 to -10 1788 o Several clarifying editorial changes, most suggested by Ted Hardie 1789 and Henry S. Thompson (some of them off-list). 1791 o Added a large number of placeholders that identify issues that 1792 require WG consideration and resolution (or WG delegation to the 1793 editors). 1795 F.3. Changes from -10 to -11 1797 o Removed most of the placeholders added in -10. Supplied new text 1798 as required or suggested by on-list discussion of those issues. 1800 o Replaced the conformance examples Section 3.2 with a more complete 1801 collection and discussion. 1803 o Revised and consolidated the registration procedure, and added 1804 provisions for NIDs that are the subject of standards and for 1805 avoiding race conditions about NID strings. 1807 o In response to independent comments from Ted Hardie and Henry S. 1808 Thompson, called attention to the possibility of conflicts between 1809 NID strings and various claims of national, corporate, and other 1810 perogatives. 1812 o Changed the production for assigned-name as suggested by Lars 1813 Svensson. 1815 o Several clarifying editorial changes including correcting a glitch 1816 in instructions to the RFC Editor. 1818 F.4. Changes from -11 to -12 1820 o Removed p-components as a standalone construct, and instead folded 1821 them into the NSS. 1823 o Defined syntax for r-components as a way to pass information to 1824 resolvers, but left the semantics for future standardization 1825 efforts. 1827 o Further tuned the discussion of interoperability and related 1828 registration issues. 1830 o Made a number of editorial corrections and reorganized the syntax 1831 material in Section 2 somewhat to make it internally consistent 1832 and keep the relationship to RFC 3986 clear. 1834 F.5. Changes from -12 to -13 1836 o More precisely defined the semantics of the optional components. 1838 o Defined the term "resolution" and clarified several related 1839 matters throughout the text. 1841 o Clarified terminological relationship to RFC 3986. 1843 o Further cleansed the document of p-components. 1845 o Corrected several examples to avoid confusion with existing 1846 identifier systems. 1848 o Improved text regarding the purpose of namespaces being 1849 registered. 1851 F.6. Changes from -13 to -14 1853 o Reverted the ABNF to what had been defined in version -12. 1855 o Added fast-track approval process for standards-related 1856 organizations, scientific societies, and similar bodies (similar 1857 to RFC 6838 for Media Types). 1859 F.7. Changes from -14 to -15 1861 o Reorganized the Introduction slightly, adding new subsection 1.1 1862 and making Terminology (the former Section 2) Section 1.2. 1864 o Tightened the discussion of "resolution" somewhat to try to 1865 mitigate some on-list confusion. 1867 o Added some text about character set choices and repertoires 1868 (consistent with the Section 1.1 explanation). 1870 o Moved away from "?" and "??" for q-component and r-component 1871 delimiters and went to two-character sequences for each. This 1872 includes several changes to the text to remove or modify 1873 discussions of string termination and the role of a question mark 1874 not followed by one of the new delimiters. 1876 o Redefined r-component to be an ASCII resolver ID and a string. 1877 Neither is further defined in this specification and text has been 1878 added to say that. 1880 o Several editorial changes to improve clarity, most following up on 1881 comments made on the list. These included modifying the table of 1882 contents so that the subsections on optional components now appear 1883 there. 1885 F.8. Changes from -15 (2016-02-04) to -16 1887 o Rewrote the introductory material to make the relationship to 1888 other specifications more clear and allow removing or altering 1889 text that was stated in terms of changes from 2141. The 1890 specification is now self-contained with regard to the earlier 1891 definitions and descriptions of URNs. 1893 o Removed the parts of Section 2 that were really a description of 1894 changes from RFC 2141 to Appendix B, where such changes are 1895 enumerated. Similarly, removed most material describing changes 1896 from RFC 3406 to Appendix C. 1898 o Replaced one example. 1900 o Rearranged and rewrote text to improve clarity and relationships 1901 to other documents and to reduce redundant material. 1903 o Made it more clear that r-components, despite the partial syntax 1904 specification, are reserved for future standardization. 1906 o Clarified that there can be URNs that do not resolve to URLs. 1908 o Added pointers to make it clear that the Syntax material in 1909 Section 2 is not self-contained, e.g., that its subsections and 1910 other sections further restrict strings that can be used for NIDs 1911 and so on. 1913 o Added an "Additional Information" section to the registration 1914 template. See list discussion on and about 2016-03-18. 1916 o Minor editorial/ typographic fixes (per comment from Lars). 1918 F.9. Changes from -16 (2016-04-16) to -17 1920 o Clarified material about copying q-components, including adding an 1921 example. 1923 o Modified the document in several places to try to respond to 1924 concerns about the unqualified use of the term "equivalence". The 1925 term has been eliminated in one or two places and changed to "URN- 1926 equivalence" in situations in which the scheme is known and URN- 1927 specific rules are being applied. 1929 o Editorial and typographic fixes. 1931 o Temporarily (this version only) added [[CREF...]] placeholders to 1932 identify outstanding issues that might usefully be discussed 1933 during the 2016-06-29 virtual meeting but that must be resolved in 1934 some way for the document to move forward. 1936 F.10. Changes from -17 (2016-06-27) to -18 1938 o Removed "cref placeholders" inserted for -17 and the 2016-06-29 1939 virtual meeting. 1941 o Per interim meeting 2016-06-29, changed "equivalent" and 1942 "equivalence" to "URN-equivalent" and "URN-equivalence" in a 1943 number of locations. 1945 o Per interim meeting 2016-06-29 and previous list discussion, 1946 clarified the usage of the terms 'name', 'namespace', 'URN 1947 namespace', 'identifier system', 'URN', and 'NSS'. 1949 o Per interim meeting 2016-06-29, changed syntax so that r-component 1950 precedes q-component. 1952 F.11. Changes from -18 (2016-09-05) to -19 1954 o Small editorial changes to improve clarity. 1956 o Added cross-references to material, especially in Section 6 and as 1957 derived from RFC 3406. 1959 o Replaced material on relative references to reflect the on-list 1960 discussions in August and September and generally to say less here 1961 and leave more to RFC 3986. 1963 o Expanded the discussion of resolution, dereferencing, 1964 representations, metadata, and intended uses for URNs. 1966 o Removed the term "abstract designator". 1968 o Replaced the term "URL" in most instances with the term "locator" 1969 or the phrase "URI that is a locator". 1971 o Rearranged and partially rewrote the "Terminology" section to 1972 reflect the above change to "URL" usage, reflect the actual use of 1973 the term "URN" in the document, and be clear about the meaning (or 1974 lack thereof) of "name". 1976 Authors' Addresses 1977 Peter Saint-Andre 1978 Filament 1979 P.O. Box 787 1980 Parker, CO 80134 1981 USA 1983 Email: peter@filament.com 1984 URI: https://filament.com/ 1986 John C Klensin 1987 1770 Massachusetts Ave, Ste 322 1988 Cambridge, MA 02140 1989 USA 1991 Phone: +1 617 245 1457 1992 Email: john-ietf@jck.com