idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-14.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 (November 1, 2015) is 3071 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) == Outdated reference: A later version (-04) exists of draft-ietf-urnbis-semantics-clarif-02 -- 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 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 URNBIS P. Saint-Andre 3 Internet-Draft &yet 4 Obsoletes: 2141, 3406 (if approved) J. Klensin 5 Intended status: Standards Track 6 Expires: May 4, 2016 November 1, 2015 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-14 11 Abstract 13 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 14 that is assigned under the "urn" scheme and a particular URN 15 namespace, with the intent that the URN will be either a persistent, 16 location-independent resource identifier or in some cases an abstract 17 designator that is persistent but that does not identify a resource. 18 With regard to URN syntax, this document defines the canonical syntax 19 for URNs (in a way that is consistent with URI syntax), specifies 20 methods for determining URN equivalence, and discusses URI 21 conformance. With regard to URN namespaces, this document specifies 22 a method for defining a URN namespace and associating it with a 23 namespace identifier, and describes procedures for registering 24 namespace identifiers with the Internet Assigned Numbers Authority 25 (IANA). This document obsoletes both RFC 2141 and RFC 3406. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 4, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Namespace Identifier . . . . . . . . . . . . . . . . . . 6 77 3.2. Namespace Specific String . . . . . . . . . . . . . . . . 6 78 3.3. Optional Components . . . . . . . . . . . . . . . . . . . 7 79 4. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 13 84 5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.3. URNs and Relative References . . . . . . . . . . . . . . 14 86 5.4. Transport and Display . . . . . . . . . . . . . . . . . . 15 87 5.5. URI Design and Ownership . . . . . . . . . . . . . . . . 15 88 6. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 17 90 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 19 91 7. Defining and Registering a URN Namespace . . . . . . . . . . 19 92 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 93 7.2. Registration Policy and Process: Community Registrations 20 94 7.3. Registration Policy and Process: Fast Track for Standards 95 Development Organizations, Scientific Societies, and 96 Similar Bodies . . . . . . . . . . . . . . . . . . . . . 21 98 7.4. Completing the Template . . . . . . . . . . . . . . . . . 22 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 25 101 8.2. Registration of URN Namespaces . . . . . . . . . . . . . 26 102 9. Security and Privacy Considerations . . . . . . . . . . . . . 26 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 105 10.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Appendix A. Registration Template . . . . . . . . . . . . . . . 29 107 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 30 108 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 30 109 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 30 110 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 31 111 Appendix F. Change log for versions of draft-ietf-urnbis- 112 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 31 113 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 31 114 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 32 115 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 32 116 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 32 117 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 33 118 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 33 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 121 1. Introduction 123 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 124 [RFC3986] that is assigned under the "urn" scheme and a particular 125 namespace, with the intent that the URN will be either a persistent, 126 location-independent resource identifier or in some cases an abstract 127 designator that is persistent but that does not identify a resource. 128 A URN namespace is a collection of such identifiers, each of which is 129 (1) unique, (2) assigned in a consistent and managed way, and (3) 130 assigned according to a common definition. (Some URN namespaces 131 create names that exist only as URNs, whereas others create URNs out 132 of names that already exist in other identifier systems, such as 133 ISBNs [RFC3187] and ISSNs [RFC3044].) 135 The assignment of URNs is done by an organization (or, in some cases, 136 according to an algorithm or other automated process) that has been 137 formally delegated a namespace within the "urn" scheme (e.g., a URN 138 in the 'example' namespace [RFC6963] might be of the form 139 "urn:example:foo"). 141 This document rests on two key assumptions: 143 1. Assignment of a URN is a managed process. 145 2. The space of URN namespaces is itself managed. 147 While other URI schemes may allow identifiers to be freely chosen and 148 assigned, such is not the case for URNs. The syntactical correctness 149 of a string starting with "urn:" is not sufficient to make it a URN. 150 In order for the string to be a valid URN, the namespace identifier 151 needs to be registered in accordance with the rules defined here and 152 the remaining parts of the assigned-name portion of the URN needs to 153 be generated in accordance with the rules for the registered 154 namespace. 156 So that information about both URN syntax and URN namespaces is 157 available in one place, this document does the following: 159 1. Defines the canonical syntax for URNs in general (in a way that 160 is consistent with URI syntax), specifies methods for determining 161 URN equivalence, and discusses URI conformance. 163 2. Specifies a method for defining a URN namespace and associating 164 it with a namespace identifier, and describes procedures for 165 registering namespace identifiers with the Internet Assigned 166 Numbers Authority (IANA). 168 For URN syntax and URN namespaces, this document modernizes and 169 replaces the definitions from [RFC2141] and [RFC3406]. These 170 modifications build on the key requirements provided in [RFC1737] and 171 many years of experience with URNs, in both cases attempting to make 172 the smallest reasonable set of changes from the previous definitions. 173 The intent is to define URNs in a consistent manner so that, wherever 174 practical, the parsing, handling, and resolution of URNs can be 175 independent of the namespace within which a given URN is assigned. 177 This document obsoletes both [RFC2141] and [RFC3406]. 179 2. Terminology 181 This document uses the terms "resolution" and "resolver" in roughly 182 the sense from [RFC2276], i.e., "resolution" is the act of supplying 183 services related to the identified resource, such as translating the 184 persistent name into one or more current locators for the resource, 185 or delivering metadata about the resource in an appropriate format. 186 At the time of this writing, resolution services are defined in 187 [RFC2483]. In order to underline the difference between the names 188 and locators, this document uses the term Uniform Resource Locator 189 (URL), rather than the generic term Uniform Resource Identifier 190 (URI), to refer to locators; see also Section 1.1.3 of [RFC3986]. 192 If there are or will be resolution services available for a URN, this 193 document calls the URN a resource identifier in roughly the sense 194 from [RFC3986]. If there is no intention to provide any resolution 195 services, this document calls the URN an abstract designator. 197 Several other important terms used in this document, including some 198 "normalization" operations that are not part of the Unicode Standard 199 [UNICODE], are defined in the URI specification [RFC3986]. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in 204 [RFC2119]. 206 3. URN Syntax 208 The syntax of URNs as provided in [RFC2141] was defined before the 209 updated specification of URIs in [RFC3986]. The definition of URN 210 syntax is updated in this document to do the following: 212 o Ensure consistency with the URI syntax. 214 o Facilitate the use of URNs with parameters similar to URI queries 215 and fragments. 217 o Permit parameters influencing URN resolution. 219 o Ease the use of URNs with naming systems that include the '/' 220 character. 222 In particular, this specification does the following: 224 o Extends URN syntax to explicitly allow the characters '/', "?", 225 and "#", which were reserved for future use by [RFC2141]; this 226 change effectively also allows several components of the URI 227 syntax although without necessarily tying those components to URI 228 semantics. 230 o Defines syntax for an additional component that can be used in 231 interactions with a URN resolution service. 233 o Makes several smaller syntax adjustments. 235 However, this specification does not extend the URN syntax to allow 236 characters outside the ASCII range [RFC20], which implies that any 237 such characters need to be percent-encoded as described in 238 Section 2.1 of the URI specification [RFC3986]. 240 The syntax for a URN is defined as follows using the Augmented 241 Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined 242 here (specifically: alphanum, fragment, and pchar) are defined as 243 part of the URI syntax [RFC3986] and used here to point out the 244 syntactic relationship with the terms used there. 246 namestring = assigned-name 247 [ "?" q-component ] 248 [ "??" r-component ] 249 [ "#" f-component ] 250 assigned-name = "urn" ":" NID ":" NSS 251 NID = (alphanum) 0*30(ldh) (alphanum) 252 ldh = alphanum / "-" 253 NSS = pchar *(pchar / "/") 254 q-component = pchar *( pchar / "/" / "?" ) 255 r-component = pchar *( pchar / "/" / "?" ) 256 f-component = fragment 258 The question mark character "?" can be used without percent-encoding 259 inside q-components, r-components, and f-components. However, it is 260 likely to cause confusion if question marks (especially consecutive 261 ones) are placed inside the r-component, or if a question mark is 262 placed at the start or end of an r-comonents or q-component; 263 therefore such usage is discouraged although not prohibited. 265 The following sections provide additional information about the 266 syntactic elements of URNs. 268 3.1. Namespace Identifier 270 The syntax here is slightly more restrictive than what was defined in 271 [RFC2141], because it prohibits the character "-" at the end of a 272 NID. 274 Note that NIDs are case insensitive (e.g., "ISBN" and "isbn" are 275 equivalent). 277 Characters outside the ASCII range [RFC20] are not permitted in NIDs, 278 and no encoding mechanism for such characters is supported. 280 3.2. Namespace Specific String 282 The namespace specific string (NSS) is a unique identifier that is 283 assigned and managed in a consistent way and that conforms to the 284 definition of the relevant namespace. The combination of the NID 285 (unique across the entire "urn" scheme) and the NSS (unique within 286 the namespace) ensures that the resulting URN is a globally unique 287 URI. 289 This document modifies the syntax of the NSS to allow the following 290 characters: "/", "~", and "&". In particular, allowing the "/" 291 character effectively makes it possible to encapsulate hierarchical 292 identifiers from other naming systems. For instance, consider the 293 hypothetical example of a hierarchical naming system in which the 294 identifiers take the form of a series of numbers separated by the "/" 295 character, such as "1/406/47452/2". If the naming authority for such 296 identifiers were to use URNs, it would be natural to place the 297 existing identifiers in the NSS, resulting in URNs such as 298 "urn:example:1/406/47452/2". 300 However, the foregoing changes to the syntax for the NSS do not 301 modify the encoding rules for URN namespaces that were defined in 302 accordance with [RFC2141]. If any such URN namespace that is used 303 outside of the URN context (i.e., as a standalone identifier space) 304 also allows the use of "/", "~", or "&" in the native form within 305 that identifier space, then the encoding rules for that namespace are 306 not changed by this specification. 308 Depending on the rules governing a namespace, names that are valid in 309 a namespace might contain characters that are not allowed by the 310 "pchar" production referenced above (e.g., characters outside the 311 ASCII range or, consistent with the restrictions in RFC 3986, the 312 characters "/", "?", "#", "[", and "]"). While such a string might 313 be a valid name, it is not a valid URN until it has been translated 314 into a conformant NSS. In the case of URNs that are formed from 315 names that exist separately in a standalone identifier space, 316 translation of an identifier from its "native" format to URN format 317 is accomplished by using the canonicalization and encoding methods 318 defined for that URN namespace. Software that is not aware of those 319 namespace-specific canonicalization and encoding rules MUST NOT 320 construct URNs from the names in the standalone identifier space. 322 In order to make URNs as stable and persistent as possible when 323 protocols evolve and the environment around them changes, namespaces 324 SHOULD NOT allow characters outside the basic Latin repertoire 325 [RFC20] unless the nature of the particular namespace makes such 326 characters necessary. 328 3.3. Optional Components 330 As compared to [RFC2141], this document extends the URN syntax to 331 permit inclusion of three new types of components: q-component, 332 r-component, and f-component. Because this specification focuses 333 almost exclusively on URN syntax, it does not define detailed 334 semantics for these components for URNs in general. However, each of 335 these components has a distinct role, which is independent of the URN 336 and its namespace, and it is intended that clients will be able to 337 handle these components uniformly for all URNs. In general: 339 o The q-component is intended for parameters to be transmitted to 340 the named resource and interpreted by that resource. 342 o The r-component is intended for parameters to be transmitted to 343 resolution services and interpreted by those services. 345 o The f-component is intended to be interpreted by the client as a 346 specification for a location within, or region of, the named 347 resource. 349 The foregoing generalizations are true regardless of the URN's 350 namespace. 352 Whenever a URN resolves to a URL which may be used to access the 353 resource, there is a more specific interpretation of q-component and 354 f-component: the q-component is copied verbatim to the query portion 355 of the URL (if that URL scheme supports query), and the f-component 356 is copied verbatim to the fragment portion of the URL. This is 357 necessary, among other reasons, so that interpretation of q-component 358 and f-component, when associated with URNs, will be consistent with 359 the interpretation of relative references containing queries or 360 fragments within documents which are ultimately accessible via URNs. 361 Thus, for URNs which may be resolved to a URL, the semantics of 362 q-component are identical to those for queries to that resource and 363 the semantics of f-components are identical to those of fragments for 364 that resource. The semantics of q-component and f-component for URNs 365 that inherently cannot be resolved to a URL (i.e., for abstract 366 designators) are undefined by this document; however, they SHOULD be 367 consistent with the above roles. It is expected that additional 368 specifications will define the semantics of r-components. 370 Note: In general, neither the syntax nor the semantics of 371 q-components or f-components are defined by, or dependent on, the 372 namespace of the URN. A particular namespace might, however, define 373 uses of r-components that are specific to its namespace and supported 374 by the resolution services which that namespace operates or 375 recommends. 377 Any of these components MAY be used with URNs from existing 378 namespaces whether or not the namespace explicitly supports them. As 379 described above, the interpretation of q-component and f-component is 380 namespace-independent. Interpretation of an r-component may be 381 namespace-dependent to some degree if it relies on behavior of a 382 namespace-specific resolution service. If a URN contains 383 r-components that are not defined by the namespace, the meaning of 384 the URN and result of resolution are out of scope for this 385 specification. 387 3.3.1. q-component 389 The URN q-component has the same syntax as the URI query component. 390 If a URN resolves to a URL with a scheme that supports a query 391 component, the q-component from the URN is copied verbatim to the 392 query component of the URL. If the URN does not resolve to a URL 393 (i.e., is an abstract designator), the interpretation of the 394 q-component is undefined by this specification. 396 The q-component is indicated by the first question mark ("?") 397 character and terminated by a double question mark ("??") indicating 398 an r-component, by a number sign ("#") character indicating an 399 f-component, or by the end of the URI. The characters slash ("/") 400 and question mark ("?") may represent data within the q-component. 401 Note that characters outside the ASCII range [RFC20] MUST be percent- 402 encoded using the method defined in Section 2.1 of the generic URI 403 specification [RFC3986]. 405 As described under Section 4, the q-component SHALL NOT be taken into 406 account when determining URN equivalence. 408 Similarly, the q-component SHALL NOT be taken into account when 409 resolving a URN to a URL and MUST NOT be used to communicate 410 parameters to a resolution service. 412 Consider the hypothetical example of passing parameters to an 413 application that returns weather reports from different regions and/ 414 or for different time periods. This could perhaps be accomplished by 415 specifying lat/long coordinates and datetimes in the URN's 416 q-component, resulting in URNs such as the following. 418 urn:example:weather?op=map&lat=39.56&lon=-104.85&datetime=1969-07-21T 419 02:56:15Z 421 However, this primary purpose is not intended to forestall other 422 potential uses for q-components for URNs that do not resolve to URLs. 424 3.3.2. r-component 426 The URN r-component has no syntactic equivalent in URIs. 428 The r-component is indicated by a double question mark ("??") and 429 terminated by a number sign ("#") character indicating an f-component 430 or by the end of the URI. The characters slash ("/") and question 431 mark ("?") may represent data within the r-component. Note that 432 characters outside the ASCII range [RFC20] MUST be percent-encoded 433 using the method defined in Section 2.1 of the generic URI 434 specification [RFC3986]. 436 As described under Section 4, the r-component SHALL NOT be taken into 437 account when determining URN equivalence. 439 However, the r-component SHALL be supplied along with the URN when 440 presenting a request to a URN resolution service. 442 The r-component is entirely intended for passing information in 443 requests to URN resolution services. The r-component is not intended 444 for passing information to the resources identified by a URN or to 445 applications that manage such resources, since that is the function 446 of the q-component. In addition, the r-component is not intended for 447 passing information to any underlying services that might exist 448 behind a resolver, only to the resolver itself. 450 This document defines only the syntax of the r-component and reserves 451 it for future use. The exact semantics of the r-component and its 452 use in URN resolution protocols are a matter for potential 453 standardization in separate specifications. 455 Consider the hypothetical example of passing parameters to resolution 456 service (say, an ISO alpha-2 country code [ISO3166-1] in order to 457 scope down the preferred country in which to search for a physical 458 copy of a book). This could perhaps be accomplished by specifying 459 the country code in the r-component, resulting in URNs such as: 461 urn:example:foo-bar-baz-qux??cc=uk 463 However, this primary purpose is not intended to forestall other 464 potential uses for r-components. 466 3.3.3. f-component 468 The URN f-component has the same syntax as the URI fragment 469 component. When a URN containing an f-component resolves to a URL, 470 the f-component from the URN is copied verbatim into the fragment of 471 that URL. If the URN does not resolve to a URL (i.e., is an abstract 472 designator), the interpretation of the f-component is undefined by 473 this specification. 475 The f-component is indicated by the presence of a number sign ("#") 476 character and terminated by the end of the URI. Note that characters 477 outside the ASCII range [RFC20] MUST be percent-encoded using the 478 method defined in Section 2.1 of the generic URI specification 479 [RFC3986]. 481 As described under Section 4, the f-component SHALL NOT be taken into 482 account when determining URN equivalence. 484 Similarly, the f-component MUST NOT be passed to resolution servers 485 when querying them for resource locations or metadata. 487 The f-component is primarily intended to distinguish the constituent 488 parts of resources named by URNs. Thus, for URNs that resolve to 489 URLs, the semantics of an f-component are defined by the media type 490 of those resources, not by the namespace. 492 Consider the hypothetical example of obtaining resources that are 493 part of a larger entity (say, the chapters of a book). Each part 494 could be specified in the f-component, resulting in URNs such as: 496 urn:example:foo-bar-baz-qux#somepart 498 However, this primary purpose is not intended to forestall other 499 potential uses for f-components for URNs that do not resolve to URLs. 501 4. Equivalence of URNs 503 4.1. Procedure 505 For various purposes such as caching, often it is desirable to 506 determine if two URNs are "the same". This is done by testing for 507 equivalence (see Section 6.1 of [RFC3986]). 509 The generic URI specification [RFC3986] is very flexible about 510 equality comparisons, putting the focus on allowing false negatives 511 and avoiding false positives. If comparisons are made in a scheme- 512 independent way, i.e., as URI comparisons only, URNs that this 513 specification considers equal would be rejected. The discussion 514 below applies when the URIs involved are known to be URNs. 516 Two URNs are equivalent if their portions are octet- 517 by-octet equal after applying case normalization (as specified in 518 Section 6.2.2.1 of [RFC3986]) to the following constructs: 520 1. the URI scheme "urn", by conversion to lower case 522 2. the NID, by conversion to lower case 524 3. any percent-encoded characters in the NSS (that is, all character 525 triplets that match the production found in 526 Section 2.1 of the base URI specification [RFC3986]), by 527 conversion to upper case for the digits A-F. 529 Percent-encoded characters MUST NOT be decoded, i.e., percent- 530 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 531 MUST NOT be applied. 533 If a q-component, r-component, or f-component (or any combination 534 thereof) are included in a URN, they MUST be ignored for purposes of 535 determining equivalence. 537 URN namespace definitions MAY include additional rules for 538 equivalence, such as case-insensitivity of the NSS (or parts 539 thereof). Such rules MUST always have the effect of eliminating some 540 of the false negatives obtained by the procedure above and MUST NOT 541 result in treating two URNs as not equivalent if the procedure here 542 says they are equivalent. For related considerations with regard to 543 NID registration, see below. 545 4.2. Examples 547 This section shows a variety of URNs (using the "example" NID defined 548 in [RFC6963]) that highlight the equivalence rules. 550 First, because the scheme and NID are case-insensitive, the following 551 URNs are equivalent to each other: 553 o urn:example:a123,z456 555 o URN:example:a123,z456 557 o urn:EXAMPLE:a123,z456 559 Second, because the q-component and f-component are not taken into 560 account for purposes of testing equivalence, the following URNs are 561 equivalent to the first three examples above: 563 o urn:example:a123,z456?abc 565 o urn:example:a123,z456#789 567 o urn:example:a123,z456#abc 569 Third, because the "/" character (and anything that follows it) in 570 the NSS is taken into account for purposes of equivalence, the 571 following URNs are not equivalent to each other or to the preceding 572 URNs: 574 o urn:example:a123,z456/foo 576 o urn:example:a123,z456/bar 577 o urn:example:a123,z456/baz 579 Fourth, because of percent-encoding, the following URNs are 580 equivalent only to each other (although %2C is the percent-encoded 581 transformation of "," from the previous examples, such sequences are 582 not decoded for purposes of testing equivalence): 584 o urn:example:a123%2Cz456 586 o URN:EXAMPLE:a123%2cz456 588 Fifth, because characters other than percent-encoded sequences in the 589 NSS are treated in a case-sensitive manner (unless otherwise 590 specified for the namespace in question), the following URNs are not 591 equivalent to the first three URNs: 593 o urn:example:A123,z456 595 o urn:example:a123,Z456 597 Sixth, on casual visual inspection of a URN presented in a human- 598 oriented interface the following URN might appear the same as the 599 first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be 600 confused with U+0061 LATIN SMALL LETTER A), but it is not equivalent: 602 o urn:example:%D0%B0123,z456 604 5. URI Conformance 606 5.1. Use in URI Protocol Slots 608 Because a URN is, syntactically, a URI under the "urn" scheme, in 609 theory a URN can be placed in any protocol slot that allows for a URI 610 (e.g., the 'href' and 'src' attributes in HTML, the element 611 in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' 612 attribute in XML for XML namespace names [XML-NAMES]). 614 However, this does not imply that, semantically, it always makes 615 sense in practice to place a URN in a given URI protocol slot; in 616 particular, because a URN might not specify the location of a 617 resource or even point indirectly to one, it might not be appropriate 618 to place a URN in a URI protocol slot that points to a resource 619 (e.g., the aforementioned 'href' and 'src' attributes). 621 Ultimately, guidelines regarding when it is appropriate to use URIs 622 under the "urn" scheme (or any other scheme) are the responsibility 623 of specifications for individual URI protocol slots (e.g., the 624 specification for the 'xml:base' attribute in XML might recommend 625 that it is inappropriate to use URNs in that protocol slot). This 626 specification cannot possibly anticipate all of the relevant cases, 627 and it is not the place of this specification to require or restrict 628 usage for individual protocol slots. 630 5.2. Parsing 632 In part because of the separation of semantics from syntax 633 [I-D.ietf-urnbis-semantics-clarif], generic URI processors need to 634 pay special attention to the parsing and analysis rules of RFC 3986 635 and, in particular, must treat the URI as opaque unless the scheme 636 and its requirements are recognized, in which case they may be in a 637 position to invoke scheme-appropriate processing such as by a URN 638 resolver. The URN resolver can either be an external resolver that 639 the URI resolver knows of, or it can be functionality built into the 640 URI resolver. Note that this requirement might impose constraints on 641 the contexts in which URNs are appropriately used; see Section 5.1. 643 5.3. URNs and Relative References 645 [RFC3986] Section 5.2 describes an algorithm for converting a URI 646 reference that might be relative to a given base URI into "parsed 647 components" of the target of that reference, which can then be 648 recomposed per RFC 3986 Section 5.3 into a target URI. This 649 algorithm cannot be applied directly to URNs because their syntax 650 does not support the necessary path components. The notion of a URN 651 as a "persistent", "permanent" identifier does not reconcile easily 652 with relative referencing. However, resources named with URNs may 653 contain relative references that do not apply to the URN itself. 655 Therefore a relative reference SHOULD NOT be evaluated directly with 656 respect to a URN. Instead, a relative reference SHOULD be evaluated 657 indirectly with respect to one of the following: 659 1. a base URI (other than a URN) declared by the resource itself; or 661 2. a base URI (other than a URN) obtained through the URN resolution 662 process; or 664 3. the URL of the resource as obtained through the URN resolution 665 process 667 (Case 2 permits the resolution process to explicitly supply a base 668 URI if the resource content is supplied directly by the resolution 669 service rather than via an intermediate "location" URI.) 671 If no such base URI exists, use of a relative reference with respect 672 to a URN is an error. Client behavior in this case is undefined. 674 Resolution services SHOULD ensure that a base URI is supplied any 675 time they provide resource content directly to a client. 677 5.4. Transport and Display 679 When URNs are transported and exchanged, they MUST be represented in 680 the format defined herein. Further, all URN-aware applications MUST 681 offer the option of displaying URNs in this canonical form to allow 682 for direct transcription (for example by cut-and-paste techniques). 683 Such applications might support display of URNs in a more human- 684 friendly form and might use a character set that includes characters 685 that are not permitted in URN syntax as defined in this specification 686 (e.g., when displaying URNs to humans, such applications might 687 replace percent-encoded strings with characters from an extended 688 character repertoire such as Unicode [UNICODE]). 690 To minimize user confusion, a URI browser SHOULD display the complete 691 URN (including the "urn" scheme and any components) to ensure that 692 there is no confusion between URN namespace identifiers and URI 693 scheme identifiers. For example, a URI beginning with "urn:xmpp:" 694 [RFC4854] is very different from a URI beginning with "xmpp:" 695 [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] is 696 different from, and possibly completely unrelated to, a possible DOI 697 URN namespace. 699 5.5. URI Design and Ownership 701 As mentioned, the assignment of URNs is a managed process, as is the 702 assignment of namespaces themselves. Although design of the URNs to 703 be assigned within a given namespace is ceded by this specification 704 to the namespace owner, doing so in a managed way avoids the problems 705 inherent in unmanaged generation of URIs as described in the 706 recommendations regarding URI design and ownership [RFC7320]. 708 6. URN Namespaces 710 A URN namespace is a collection of identifiers that obey three 711 constraints: each identifier is (1) unique, (2) assigned in a 712 consistent way, and (3) assigned according to a common definition. 714 1. The "uniqueness" constraint means that an identifier within the 715 namespace is never assigned to more than one resource and never 716 reassigned to a different resource (for the kind of "resource" 717 identified by URNs assigned within the namespace). This holds 718 true even if the identifier itself is deprecated or becomes 719 obsolete. 721 2. The "consistent assignment" constraint means that an identifier 722 within the namespace is assigned by an organization or created in 723 accordance with a process or algorithm that is always followed. 725 3. The "common definition" constraint means that there are clear 726 definitions for the syntax of identifiers within the namespace 727 and for the process of assigning or creating them. 729 A URN namespace is identified by a particular NID in order to ensure 730 the global uniqueness of URNs and, optionally, to provide a cue 731 regarding the structure of URNs assigned within a namespace. 733 With regard to global uniqueness, using different NIDs for different 734 collections of identifiers ensures that no two URNs will be the same 735 for different resources, since each collection is required to 736 uniquely assign each identifier. However, a single resource MAY have 737 more than one URN assigned to it, either in the same namespace (if 738 the namespace permits it) or in different namespaces, and either for 739 similar purposes or different purposes. (For example, if a book were 740 published in a monograph series, it could have both an ISBN [RFC3187] 741 and an ISSN [RFC3044] assigned to it, resulting in two URNs referring 742 to the same book.) Subject to other constraints, such as those 743 imposed by the URI syntax [RFC3986], the rules of the URN scheme are 744 intended to allow preserving the normal and natural form of 745 identifiers specified elsewhere when they are treated as URN 746 namespaces. 748 With regard to the structure of URNs assigned within a namespace, the 749 development of an identifier structure (and thereby a collection of 750 identifiers) depends on the requirements of the community defining 751 the identifiers, how the identifiers will be assigned and used, etc. 752 These issues are beyond the scope of URN syntax and the general rules 753 for URN namespaces, because they are specific to the community 754 defining a namespace (e.g., the bibliographic and publishing 755 communities in the case of the 'ISBN' and 'ISSN' namespaces, or the 756 developers of extensions to the Extensible Messaging and Presence 757 Protocol in the case of the 'XMPP' namespace). 759 URN namespaces inherit certain rights and responsibilities by the 760 nature of URNs, e.g.: 762 1. They uphold the general principles of a well-managed URN 763 namespace by providing persistent identification of resources and 764 unique assignment of identifier strings in accordance with a 765 common definition. 767 2. Optionally, they can be registered in global registration 768 services. 770 There are two types of URN namespace: formal and informal. These are 771 distinguished by the expected level of service, the information 772 needed to define the namespace, and the procedures for registration. 773 Because the majority of the namespaces registered so far have been 774 formal, this document concentrates on formal namespaces. 776 Note: [RFC3406] defined a third type of "experimental namespaces", 777 denoted by prefixing the namespace identifier with the string "X-". 778 Consistent with general IETF conclusions about similar approaches 779 [RFC6648], this specification removes the experimental category and 780 syntax. Because experimental namespaces were never registered, 781 removing the experimental category has no impact on the existing 782 registries. However, to avoid the potential for conflict between 783 previously-allowed unregistered experimental namespaces and 784 namespaces registered in the future, no registrations will be 785 accepted for new namespaces beginning with "X-". Because they are 786 not registered, strings that refer to experimental namespaces are not 787 valid URNs. Truly experimental usages MAY, of course, employ the 788 'example' namespace [RFC6963]. 790 6.1. Formal Namespaces 792 A formal namespace provides benefit to some subset of users on the 793 Internet. In particular, it would not make sense for a formal 794 namespace to be used only by a community or network that is not 795 connected to the Internet. For example, it would be inappropriate 796 for a NID to effectively force someone to use a proprietary network 797 or service not open to the general Internet user. The intent is 798 that, while the community of those who might actively use the names 799 assigned within that NID might be small, the potential use of 800 identifiers within that NID is open to any user on the Internet. 801 Formal NIDs might be appropriate even when some aspects are not fully 802 open. For example, a namespace might make use of a fee-based, 803 privately managed, or proprietary registry for assignment of URNs in 804 the namespace. However, it might still benefit some Internet users 805 if the associated services have openly-published identifiers. 807 An organization that will assign URNs within a formal namespace 808 SHOULD meet the following criteria: 810 1. Organizational stability and the ability to maintain the URN 811 namespace for a long time; absent such evidence, it ought to be 812 clear how the namespace can remain viable if the organization can 813 no longer maintain the namespace. 815 2. Competency in name assignment. This will improve the likelihood 816 of persistence (e.g. to minimize the likelihood of conflicts). 818 3. Commitment to not reassigning existing names and to allowing old 819 names to continue to be valid (e.g., if the assignee of a name is 820 no longer a member or customer of the assigning organization, if 821 various information about the assignee or named entity happens to 822 change, or even if the assignee or the named entity itself is no 823 longer in existence; in all these cases, the name is still 824 valid). 826 A formal namespace establishes a particular NID, subject to the 827 following constraints (above and beyond the syntax rules already 828 specified): 830 1. It MUST NOT be an already-registered NID. 832 2. It MUST NOT start with "urn-" (which is reserved for informal 833 namespaces). 835 3. It MUST be more than two characters long. 837 4. It MUST NOT start with ALPHA ALPHA "-", i.e., any string 838 consisting of two letters followed by one hyphen. 840 5. It MUST NOT start with the string "xn--" or any other string 841 consisting of two letters followed by two hyphens. Such strings 842 are reserved for potential representation of DNS A-labels and 843 similar strings in the future [RFC5890]. 845 6. It MUST NOT start with the string "X-" so that it will not be 846 confused with or conflict any experimental namespace previously 847 permitted by [RFC3406]. 849 All two-letter strings, and all two-letter strings followed by "-" 850 and any sequence of valid NID characters, are reserved for potential 851 use as NIDs based on ISO alpha-2 country codes [ISO3166-1] for 852 eventual national registrations of URN namespaces. The definition 853 and scoping of rules for allocation of responsibility for such 854 country-code-based namespaces is beyond the scope of this document. 856 Applicants and reviewers considering new NIDs should also be aware 857 that they may be considered as names with semantic implications and 858 hence a source of conflict. Particular attention should be paid to 859 strings that might be construed as names of, or registered under the 860 authority of, countries (including ISO 3166-1 alpha-3 codes) and to 861 strings that might imply association with existing URI schemes, 862 identifier systems, or trademarks. However, in line with traditional 863 policies, disputes about "ownership" of particular strings are 864 disagreements among the parties involved; neither IANA nor the IETF 865 will become involved in such disputes except in response to orders 866 from a court of competent jurisdiction. 868 6.2. Informal Namespaces 870 Informal namespaces are full-fledged URN namespaces, with all the 871 associated rights and responsibilities. Informal namespaces differ 872 from formal namespaces in the process for assigning a NID: for an 873 informal namespace, the registrant does not designate the NID; 874 instead, IANA assigns a NID consisting of the string 'urn-' followed 875 by one or more digits (e.g., "urn-7") where the digits consist of the 876 next available number in the sequence of positive integers assigned 877 to informal namespaces. Thus the syntax of an informal namespace is: 879 InformalNamespaceName = "urn-" Number 880 Number = DigitNonZero 0*Digit 881 DigitNonZero = "1"/ "2" / "3" / "4"/ "5" 882 / "6" / "7" / "8" / "9" 883 Digit = "0" / DigitNonZero 885 The only restrictions on are that it (1) consist strictly of 886 ASCII digits, that it (2) not have leading zeros, and that it (3) not 887 cause the NID to exceed the length limitations defined for the URN 888 syntax. 890 7. Defining and Registering a URN Namespace 892 7.1. Overview 894 Because the space of URN namespaces is itself managed, the definition 895 of a namespace SHOULD pay particular attention to: 897 1. The purpose of the namespace. 899 2. The syntax of URNs assigned within the namespace, including 900 whether q-components, r-components, or f-components are allowed. 902 3. The process for assigning URNs within the namespace. 904 4. The security implications of assigning URNs within the namespace 905 and using the assigned URNs. 907 5. Any potential interoperability issues with URNs assigned within 908 the namespace. 910 6. Optionally, the process for resolving URNs issued within the 911 namespace. 913 The section on completing the template (Section 7.4) explains these 914 matters in greater detail. While the registration templates are the 915 same, slightly different procedures are used depending on the source 916 of the registration. 918 7.2. Registration Policy and Process: Community Registrations 920 The basic registration policy for URN namespaces is Expert Review as 921 defined in the "IANA Considerations" document [RFC5226]. For 922 namespaces or their definitions that are intended to become standards 923 or normative components of standards, the output of the Expert Review 924 process is intended to be a report, rather than instructions to IANA 925 to take action (see below). The key steps are: 927 1. Fill out the namespace registration template (see Section 7.4 and 928 Appendix A). This can be done as part of an Internet-Draft or a 929 specification in another series, although that is not necessary. 931 2. Send the completed template to the urn@ietf.org discussion list 932 for review. 934 3. If necessary to address comments received, repeat steps 1 and 2. 936 4. If the designated experts approve the request and no 937 standardization action is involved, the IANA will register the 938 requested NID. If standardization is anticipated, the designated 939 experts will prepare a report and forward it to the appropriate 940 standards approval body (the IESG in the case of the IETF) and 941 IANA will register the requested NID only after receiving 942 directions from that body and a copy of the expert review report. 944 A namespace registration can be revised by updating the registration 945 template, following the same steps outlined above for new 946 registrations. A revised registration MUST describe differences from 947 prior versions and SHOULD make special note of any relevant changes 948 in the underlying technologies or namespace management processes. 950 Experience to date with namespace registration requests has shown 951 that registrants sometimes do not initially understand some of the 952 subtleties of URN namespaces, and that defining the namespace in the 953 form of a specification enables the registrants to clearly formulate 954 their "contract" with the intended user community. Therefore, 955 although the registration policy for formal namespaces is Expert 956 Review and a specification is not strictly required, it is 957 RECOMMENDED for registrants to provide a stable specification 958 documenting the namespace definition and expanding upon the issues 959 described herein. 961 Because naming can be difficult and contentious, namespace 962 registrants and the designated experts are strongly encouraged to 963 work together in a spirit of good faith and mutual understanding to 964 achieve rough consensus (see [RFC7282]) on handling registration 965 requests. They are also encouraged to bring additional expertise 966 into the discussion if that would be helpful in providing perspective 967 or otherwise resolving issues. 969 Especially when iterations in the registration process are prolonged, 970 designated experts are expected to take reasonable precautions to 971 avoid race conditions on proposed NID names and, if such situations 972 arise, to encourage applicants to work out any conflicts among 973 themselves. 975 7.3. Registration Policy and Process: Fast Track for Standards 976 Development Organizations, Scientific Societies, and Similar 977 Bodies 979 The IETF recognizes that situations will arise in which URN 980 namespaces will be created to either embed existing and established 981 standards or to reflect knowledge, terminology, or information 982 organization that lie well outside the IETF's scope or the likely 983 subject matter knowledge of its Designated Experts. In situations in 984 which the registration request originates from, or is authorized by, 985 a recognized standards-related organization, scientific society, or 986 similar body, a somewhat different procedure is available at the 987 option of that body: 989 1. The namespace registration template is filled out and submitted 990 as in steps 1 and 2 above. 992 2. A specification is required that reflects of points to the needed 993 external standards or specifications. Publication in the RFC 994 Series or through an IETF process (e.g., posting as an Internet 995 Draft) is not expected and would be appropriate only under very 996 unusual circumstances. 998 3. The reviews on the discussion list and by the designated experts 999 are, however, strictly advisory, with the decisions about what 1000 advice to accept and the length of time to allocate to the 1001 process strictly under the control of the external body. 1003 4. When that body concludes that the application is sufficiently 1004 mature, they will request that IANA will complete the 1005 registration for the NID and IANA will do so. 1007 Decisions about whether to recognize the requesting entity as a 1008 standards-related organization, scientific society, or similar body 1009 are the responsibility of the IESG. 1011 Note that a similar model has already been defined for recognized 1012 standards-related organizations that wish to register Media Types. 1013 The document describing that mechanism [RFC6838] provides somewhat 1014 more information about the general approach. 1016 7.4. Completing the Template 1018 A template for defining and registering a URN namespace is provided 1019 in Appendix A. This section describes considerations for completing 1020 the template. 1022 7.4.1. Purpose 1024 The "Purpose" section of the template describes matters such as: 1026 1. The kinds of resources identified by URNs assigned within the 1027 namespace. 1029 2. The scope and applicability of the URNs assigned within the 1030 namespace; this might include information about the community of 1031 use (e.g., a particular nation, industry, technology, or 1032 organization), whether the assigned URNs will be used on public 1033 networks or private networks, etc. 1035 3. How the intended community (and the Internet community at large) 1036 will benefit from using or resolving the assigned URNs. 1038 4. How the namespace relates to and complements existing URN 1039 namespaces, URI schemes, and identifier systems. 1041 5. The kinds of software applications that can use or resolve the 1042 assigned URNs (e.g., by differentiating among disparate 1043 namespaces, identifying resources in a persistent fashion, or 1044 meaningfully resolving and accessing services associated with the 1045 namespace). 1047 6. Whether resolution services are available or will be available 1048 (and, if so, the nature or identity of the services). Examples 1049 of q- and r-component semantics and syntax are helpful here, even 1050 if they are registered or defined elsewhere later. 1052 7. Whether the namespace or its definition are expected to become an 1053 integral or normative element of a standard being developed in 1054 the IETF or some other recognized standards body. 1056 7.4.2. Syntax 1058 The "Syntax" section of the template contains: 1060 1. A description of the structure of URNs within the namespace, in 1061 conformance with the fundamental URN syntax. The structure might 1062 be described in terms of a formal definition (e.g., using 1063 Augmented BNF for Syntax Specifications (ABNF) as specified in 1064 [RFC5234]), an algorithm for generating conformant URNs, or a 1065 regular expression for parsing the identifier into components; 1066 alternatively, the structure might be opaque. 1068 2. Any special character encoding rules for assigned URNs (e.g., 1069 which character ought to always be used for quotes). 1071 3. Rules for determining equivalence between two identifiers in the 1072 namespace. Such rules ought to always have the effect of 1073 eliminating false negatives that might otherwise result from 1074 comparison. If it is appropriate and helpful, reference can be 1075 made to specific equivalence rules defined in the URI 1076 specification [RFC3986]. Examples of equivalence rules include 1077 equivalence between uppercase and lowercase characters in the 1078 Namespace Specific String, between hyphenated and non-hyphenated 1079 groupings in the identifier string, or between single-quotes and 1080 double-quotes. (Note that these are not normative statements for 1081 any kind of best practice related to handling of equivalences 1082 between characters in general; they are statements limited to one 1083 particular namespace only.) 1085 4. Any special considerations necessary for conforming with the URN 1086 syntax. This is particularly applicable in the case of existing 1087 naming systems that are used in the context of URNs. For 1088 example, if a namespace is used in contexts other than URNs, it 1089 might make use of characters that are reserved in the URN syntax. 1090 This section ought to note any such characters, and outline 1091 necessary mappings to conform to URN syntax. Normally, this will 1092 be handled by percent-encoding the character as specified in 1093 Section 2.1 of the URI specification [RFC3986]. 1095 7.4.3. Assignment 1097 The "Assignment" section of the template describes matters such as: 1099 1. Mechanisms or authorities for assigning URNs to resources. It 1100 ought to make clear whether assignment is completely open (e.g., 1101 following a particular procedure such as first-come, first-served 1102 (FCFS)), completely closed (e.g., for a private organization), or 1103 limited in various ways (e.g., delegated to authorities 1104 recognized by a particular organization); if limited, it ought to 1105 explain how to become an assigner of identifiers or how to 1106 request assignment of identifiers from existing assignment 1107 authorities. 1109 2. Methods for ensuring that URNs within the namespace are unique. 1110 For example, identifiers might be assigned sequentially or in 1111 accordance with some well-defined process by a single authority, 1112 assignment might be partitioned among delegated authorities that 1113 are individually responsible for respecting uniqueness rules, or 1114 URNs might be created independently following an algorithm that 1115 itself guarantees uniqueness. 1117 7.4.4. Security and Privacy 1119 The "Security and Privacy" section of the template describes any 1120 potential issues related to security and privacy with regard to 1121 assignment, use, and resolution of identifiers within the namespace. 1122 Examples of such issues include: 1124 o The consequences of producing false negatives and false positives 1125 during comparison for equivalence (see "Issues in Identifier 1126 Comparison for Security Purposes" [RFC6943]) 1128 o Leakage of private information when identifiers are communicated 1129 on the public Internet 1131 o The potential for directory harvesting 1133 o Various issues discussed in the guidelines for security 1134 considerations in RFCs [RFC3552] and the privacy considerations 1135 for Internet protocols [RFC6973]. 1137 7.4.5. Interoperability 1139 The "Interoperability" section MUST specify any potential issues 1140 related to interoperability. Examples include possible confusion 1141 with other URN namespaces or naming systems because of syntax (e.g., 1142 percent-encoding of certain characters) or scope (e.g., overlapping 1143 areas of interest). If at all possible, concerns that arise during 1144 the registration of a URN namespace (e.g., due to the syntax or scope 1145 of an identifier system) SHOULD be resolved as part of the 1146 registration process. 1148 7.4.6. Resolution 1150 The "Resolution" section MUST specify whether resolution mechanisms 1151 are intended or anticipated for URNs assigned within the namespace 1152 (e.g., URNs within some namespaces are intended to act as abstract 1153 designators and thus are not intended to be resolved). 1155 If resolution is intended, then this section SHOULD specify whether 1156 the organization that assigns URNs within the namespace intends to 1157 operate or recommend any resolution services for URNs within that 1158 namespace. In addition, if the assigning organization intends to 1159 implement registration for publicly advertised resolution services 1160 (for example using a system based on principles similar to those 1161 described in [RFC2276] and [RFC2483]), then this section SHOULD list 1162 or reference the requirements for being publicly advertised by the 1163 assigning organization. 1165 8. IANA Considerations 1167 8.1. URI Scheme 1169 This section updates the registration of the 'urn' URI scheme in the 1170 Permanent URI Registry [URI-Registry] . 1172 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 1173 and the number assigned to this document upon publication.] 1175 URI Scheme Name: urn 1177 Status: permanent 1179 URI Scheme Syntax: See Section 3 of [ this document ]. 1181 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 1182 Names, which are persistent, location-independent resource 1183 identifiers. 1185 Encoding Considerations: See Section 3 of [ this document ]. 1187 Applications/Protocols That Use This URI Scheme Name: Uniform 1188 Resource Names are used in a wide variety of applications, 1189 including bibliographic reference systems and as names for 1190 Extensible Markup Language (XML) namespaces. 1192 Interoperability Considerations: See Section 5 of [ this document ]. 1194 Security Considerations: See Section 7.4.4 and Section 9 of [ this 1195 document ]. 1197 Contact: URNBIS WG [mailto:urn@ietf.org] 1199 Author/Change Controller: This scheme is registered under the IETF 1200 tree. As such, the IETF maintains change control. 1202 References None. 1204 8.2. Registration of URN Namespaces 1206 This document outlines the processes for registering URN namespaces, 1207 and has implications for the IANA in terms of registries to be 1208 maintained (see especially Section 7). In all cases, the IANA ought 1209 to assign the appropriate NID (formal or informal) once the 1210 procedures outlined in this document have been completed. 1212 9. Security and Privacy Considerations 1214 The definition of a URN namespace needs to account for potential 1215 security and privacy issues related to assignment, use, and 1216 resolution of identifiers within the namespace (e.g., some namespace 1217 resolvers might assign special meaning to certain characters in the 1218 Namespace Specific String); see Section 7.4.4 for further discussion. 1220 In most cases, URN namespaces provide a way to declare public 1221 information. Nominally, these declarations will have a relatively 1222 low security profile, however there is always the danger of 1223 "spoofing" and providing misinformation. Information in these 1224 declarations ought to be taken as advisory. 1226 10. References 1228 10.1. Normative References 1230 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 1231 October 1969. 1233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1234 Requirement Levels", BCP 14, RFC 2119, March 1997. 1236 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1237 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1238 3986, January 2005. 1240 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1241 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1242 May 2008. 1244 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1245 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1247 10.2. Informative References 1249 [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The 1250 "doi" URI Scheme for the Digital Object Identifier (DOI)", 1251 June 2003, 1252 . 1254 [I-D.ietf-urnbis-semantics-clarif] 1255 Klensin, J., "URN Semantics Clarification", draft-ietf- 1256 urnbis-semantics-clarif-02 (work in progress), August 1257 2015. 1259 [ISO3166-1] 1260 ISO, "Codes for the representation of names of countries 1261 and their subdivisions -- Part 1: Country codes", ISO 1262 3166-1:2013, 2013. 1264 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1265 Uniform Resource Names", RFC 1737, December 1994. 1267 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1269 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1270 Name Resolution", RFC 2276, January 1998. 1272 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1273 Necessary for URN Resolution", RFC 2483, January 1999. 1275 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1276 Standard Number) as URN (Uniform Resource Names) within an 1277 ISSN-URN Namespace", RFC 3044, January 2001. 1279 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1280 Book Numbers as Uniform Resource Names", RFC 3187, October 1281 2001. 1283 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1284 "Uniform Resource Names (URN) Namespace Definition 1285 Mechanisms", BCP 66, RFC 3406, October 2002. 1287 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1288 Text on Security Considerations", BCP 72, RFC 3552, July 1289 2003. 1291 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1292 for Extensions to the Extensible Messaging and Presence 1293 Protocol (XMPP)", RFC 4854, April 2007. 1295 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1296 (IRIs) and Uniform Resource Identifiers (URIs) for the 1297 Extensible Messaging and Presence Protocol (XMPP)", RFC 1298 5122, February 2008. 1300 [RFC5890] Klensin, J., "Internationalized Domain Names for 1301 Applications (IDNA): Definitions and Document Framework", 1302 RFC 5890, August 2010. 1304 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1305 "Deprecating the "X-" Prefix and Similar Constructs in 1306 Application Protocols", BCP 178, RFC 6648, June 2012. 1308 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1309 Specifications and Registration Procedures", BCP 13, RFC 1310 6838, January 2013. 1312 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1313 Purposes", RFC 6943, May 2013. 1315 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1316 for Examples", BCP 183, RFC 6963, May 2013. 1318 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1319 Morris, J., Hansen, M., and R. Smith, "Privacy 1320 Considerations for Internet Protocols", RFC 6973, July 1321 2013. 1323 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 1324 7282, June 2014. 1326 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1327 7320, July 2014. 1329 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-, 1330 . 1332 [URI-Registry] 1333 IANA, "Permanent URI Schemes", . 1336 [XML-BASE] 1337 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1338 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1339 January 2009, 1340 . 1342 [XML-NAMES] 1343 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1344 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1345 Web Consortium Recommendation REC-xml-names-20091208, 1346 December 2009, 1347 . 1349 Appendix A. Registration Template 1351 Namespace ID: Requested of IANA (formal) or assigned by IANA 1352 (informal). 1354 Version: The version of the registration, starting with 1 and 1355 incrementing by 1 with each new version. 1357 Date: The date when the registration is requested of IANA, using the 1358 format YYYY-MM-DD. 1360 Registrant: The person or organization that has registered the NID, 1361 including the name and address of the registering organization, as 1362 well as the name and contact information (email, phone number, or 1363 postal address) of the designated contact person. If the 1364 registrant is a recognized standards development organization or 1365 scientific society requesting the fact track registration 1366 procedure (see Section 7.3), that information should be clearly 1367 indicated in this section of the template. 1369 Purpose: Described under Section 7.4.1 of this document. 1371 Syntax: Described under Section 7.4.2 of this document. Unless the 1372 registration explicitly says otherwise, use of q-components and 1373 f-components is not allowed for this namespace. 1375 Assignment: Described under Section 7.4.3 of this document. 1377 Security and Privacy: Described under Section 7.4.4 of this 1378 document. 1380 Interoperability: Described under Section 7.4.5 of this document. 1382 Resolution: Described under Section 7.4.6 of this document. 1384 Documentation A pointer to an RFC, a specification published by 1385 another standards development organization, or another stable 1386 document that provides further information about the namespace. 1388 Revision Information: Description of changes from prior version(s). 1389 (Applicable only when earlier registrations have been revised.) 1391 Appendix B. Changes from RFC 2141 1393 This document makes the following substantive changes from [RFC2141]: 1395 o Formally registers 'urn' as a URI scheme. 1397 o Disallows "-" at the end of a NID. 1399 o Allows the "/", "~", and "&" characters in the namespace-specific 1400 string (NSS). 1402 o Allows q-components, r-components, and f-components. 1404 Appendix C. Changes from RFC 3406 1406 This document makes the following substantive changes from [RFC3406]: 1408 1. Relaxes the registration policy for formal namespaces from "IETF 1409 Review" to "Expert Review" as discussed in Section 7.2. 1411 2. Removes the category of experimental namespaces, consistent with 1412 [RFC6648]. 1414 3. Simplifies the registration template. 1416 In addition, some of the text has been updated to be consistent with 1417 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1418 the processes for registering information with the IANA [RFC5226], as 1419 well as more modern guidance with regard to security [RFC3552] and 1420 privacy [RFC6973] issues and identifier comparison [RFC6943]. 1422 Appendix D. Contributors 1424 RFC 2141, which provided the basis for the syntax portion of this 1425 document, was authored by Ryan Moats. 1427 RFC 3406, which provided the basis for the namespace portion of this 1428 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1429 Renato Iannella, and Patrik Faltstrom. 1431 Their work is gratefully acknowledged. 1433 Appendix E. Acknowledgements 1435 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1436 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1437 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1438 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1439 participants in the URNBIS WG for their input. Alfred Hoenes in 1440 particular edited an earlier version of this document and served as 1441 co-chair of the URNBIS WG. 1443 Juha Hakala deserves special recognition for his dedication to 1444 successfully completing this work, as do Andrew Newton and Melinda 1445 Shore in their roles as working group co-chairs and Barry Leiba in 1446 his role as area director. 1448 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1450 [[RFC Editor: please remove this appendix before publication.]] 1452 F.1. Changes from -08 to -09 1454 o Altered the text in Section 5 to reflect list discussions about 1455 the earlier phrasing. Also added DOI example and citation to that 1456 section. 1458 o Clarified the naming rules for formal namespaces and their 1459 relationship to ISO 3166, IDNA, etc., reserved strings. 1461 o Added an explicit statement about use of URNs in various protocols 1462 and contexts to Section 5. 1464 o Clarified that experimental namespace NIDs, which were explicitly 1465 not registered, are not valid URNs (in Section 6. 1467 o Transformed the partial production in Section 6.2 into valid ABNF. 1469 o Added more text about p-/q-/f-components and recommendations about 1470 use. 1472 o Added clarifying note about "?" within q-components and 1473 f-components. 1475 o Added explicit requirement that revisions of existing 1476 registrations document the changes and added a slot for that 1477 description to the template. 1479 o Many small editorial changes and adjustments including adding 1480 additional references and cross-references for clarification. 1482 o Inserted a placeholder for additional examples. 1484 F.2. Changes from -09 to -10 1486 o Several clarifying editorial changes, most suggested by Ted Hardie 1487 and Henry S. Thompson (some of them off-list). 1489 o Added a large number of placeholders that identify issues that 1490 require WG consideration and resolution (or WG delegation to the 1491 editors). 1493 F.3. Changes from -10 to -11 1495 o Removed most of the placeholders added in -10. Supplied new text 1496 as required or suggested by on-list discussion of those issues. 1498 o Replaced the conformance examples Section 4.2 with a more complete 1499 collection and discussion. 1501 o Revised and consolidated the registration procedure, and added 1502 provisions for NIDs that are the subject of standards and for 1503 avoiding race conditions about NID strings. 1505 o In response to independent comments from Ted Hardie and Henry S. 1506 Thompson, called attention to the possibility of conflicts between 1507 NID strings and various claims of national, corporate, and other 1508 perogatives. 1510 o Changed the production for assigned-name as suggested by Lars 1511 Svensson. 1513 o Several clarifying editorial changes including correcting a glitch 1514 in instructions to the RFC Editor. 1516 F.4. Changes from -11 to -12 1518 o Removed p-components as a standalone construct, and instead folded 1519 them into the NSS. 1521 o Defined syntax for r-components as a way to pass information to 1522 resolvers, but left the semantics for future standardization 1523 efforts. 1525 o Further tuned the discussion of interoperability and related 1526 registration issues. 1528 o Made a number of editorial corrections and reorganized the syntax 1529 material in Section 3 somewhat to make it internally consistent 1530 and keep the relationship to RFC 3986 clear. 1532 F.5. Changes from -12 to -13 1534 o More precisely defined the semantics of the optional components. 1536 o Defined the term "resolution" and clarified several related 1537 matters throughout the text. 1539 o Clarified terminological relationship to RFC 3986. 1541 o Further cleansed the document of p-components. 1543 o Corrected several examples to avoid confusion with existing 1544 identifier systems. 1546 o Improved text regarding the purpose of namespaces being 1547 registered. 1549 F.6. Changes from -13 to -14 1551 o Reverted the ABNF to what had been defined in version -12. 1553 o Added fast-track approval process for standards-related 1554 organizations, scientific societies, and similar bodies (similar 1555 to RFC 6838 for Media Types). 1557 Authors' Addresses 1559 Peter Saint-Andre 1560 &yet 1562 Email: peter@andyet.com 1563 URI: https://andyet.com/ 1565 John C Klensin 1566 1770 Massachusetts Ave, Ste 322 1567 Cambridge, MA 02140 1568 USA 1570 Phone: +1 617 245 1457 1571 Email: john-ietf@jck.com