idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-13.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 (September 14, 2015) is 3144 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: March 17, 2016 September 14, 2015 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-13 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 March 17, 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 . . . . . . . . . . . . . 20 94 7.3. Completing the Template . . . . . . . . . . . . . . . . . 21 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 96 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.2. Registration of URN Namespaces . . . . . . . . . . . . . 25 98 9. Security and Privacy Considerations . . . . . . . . . . . . . 25 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 101 10.2. Informative References . . . . . . . . . . . . . . . . . 26 102 Appendix A. Registration Template . . . . . . . . . . . . . . . 28 103 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 29 104 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 29 105 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 29 106 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29 107 Appendix F. Change log for versions of draft-ietf-urnbis- 108 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 30 109 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 30 110 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 31 111 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 31 112 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 31 113 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 32 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 119 [RFC3986] that is assigned under the "urn" scheme and a particular 120 namespace, with the intent that the URN will be either a persistent, 121 location-independent resource identifier or in some cases an abstract 122 designator that is persistent but that does not identify a resource. 123 A URN namespace is a collection of such identifiers, each of which is 124 (1) unique, (2) assigned in a consistent and managed way, and (3) 125 assigned according to a common definition. (Some URN namespaces 126 create names that exist only as URNs, whereas others create URNs out 127 of names that already exist in other identifier systems, such as 128 ISBNs [RFC3187] and ISSNs [RFC3044].) 130 The assignment of URNs is done by an organization (or, in some cases, 131 according to an algorithm or other automated process) that has been 132 formally delegated a namespace within the "urn" scheme (e.g., a URN 133 in the 'example' namespace [RFC6963] might be of the form 134 "urn:example:foo"). 136 This document rests on two key assumptions: 138 1. Assignment of a URN is a managed process. 140 2. The space of URN namespaces is itself managed. 142 While other URI schemes may allow identifiers to be freely chosen and 143 assigned, such is not the case for URNs. The syntactical correctness 144 of a string starting with "urn:" is not sufficient to make it a URN. 146 In order for the string to be a valid URN, the namespace identifier 147 needs to be registered in accordance with the rules defined here and 148 the remaining parts of the assigned-name portion of the URN needs to 149 be generated in accordance with the rules for the registered 150 namespace. 152 So that information about both URN syntax and URN namespaces is 153 available in one place, this document does the following: 155 1. Defines the canonical syntax for URNs in general (in a way that 156 is consistent with URI syntax), specifies methods for determining 157 URN equivalence, and discusses URI conformance. 159 2. Specifies a method for defining a URN namespace and associating 160 it with a namespace identifier, and describes procedures for 161 registering namespace identifiers with the Internet Assigned 162 Numbers Authority (IANA). 164 For URN syntax and URN namespaces, this document modernizes and 165 replaces the definitions from [RFC2141] and [RFC3406]. These 166 modifications build on the key requirements provided in [RFC1737] and 167 many years of experience with URNs, in both cases attempting to make 168 the smallest reasonable set of changes from the previous definitions. 169 The intent is to define URNs in a consistent manner so that, wherever 170 practical, the parsing, handling, and resolution of URNs can be 171 independent of the namespace within which a given URN is assigned. 173 This document obsoletes both [RFC2141] and [RFC3406]. 175 2. Terminology 177 This document uses the terms "resolution" and "resolver" in roughly 178 the sense from [RFC2276], i.e., "resolution" is the act of supplying 179 services related to the identified resource, such as translating the 180 persistent name into one or more current locators for the resource, 181 or delivering metadata about the resource in an appropriate format. 182 At the time of this writing, resolution services are defined in 183 [RFC2483]. In order to underline the difference between the names 184 and locators, this document uses the term Uniform Resource Locator 185 (URL), rather than the generic term Uniform Resource Identifier 186 (URI), to refer to locators; see also Section 1.1.3 of [RFC3986]. 188 If there are or will be resolution services available for a URN, this 189 document calls the URN a resource identifier in roughly the sense 190 from [RFC3986]. If there is no intention to provide any resolution 191 services, this document calls the URN an abstract designator. 193 Several other important terms used in this document, including some 194 "normalization" operations that are not part of the Unicode Standard 195 [UNICODE], are defined in the URI specification [RFC3986]. 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119]. 202 3. URN Syntax 204 The syntax of URNs as provided in [RFC2141] was defined before the 205 updated specification of URIs in [RFC3986]. The definition of URN 206 syntax is updated in this document to do the following: 208 o Ensure consistency with the URI syntax. 210 o Facilitate the use of URNs with parameters similar to URI queries 211 and fragments. 213 o Permit parameters influencing URN resolution. 215 o Ease the use of URNs with naming systems that include the '/' 216 character. 218 In particular, this specification does the following: 220 o Extends URN syntax to explicitly allow the characters '/', "?", 221 and "#", which were reserved for future use by [RFC2141]; this 222 change effectively also allows several components of the URI 223 syntax although without necessarily tying those components to URI 224 semantics. 226 o Defines syntax for an additional component that can be used in 227 interactions with a URN resolution service. 229 o Makes several smaller syntax adjustments. 231 However, this specification does not extend the URN syntax to allow 232 characters outside the ASCII range [RFC20], which implies that any 233 such characters need to be percent-encoded as described in 234 Section 2.1 of the URI specification [RFC3986]. 236 The syntax for a URN is defined as follows using the Augmented 237 Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined 238 here (specifically: alphanum, fragment, and pchar) are defined as 239 part of the URI syntax [RFC3986] and used here to point out the 240 syntactic relationship with the terms used there. 242 namestring = assigned-name 243 [ "?" q-component ] 244 [ "??" r-component ] 245 [ "#" f-component ] 246 assigned-name = "urn" ":" NID ":" NSS 247 NID = (alphanum) 0*30(ldh) (alphanum) 248 ldh = alphanum / "-" 249 NSS = word 250 q-component = word *phrase 251 r-component = word *phrase 252 word = pchar *(pchar / "/") 253 phrase = "?" word 254 f-component = fragment 256 Note: The character "?" can be used without percent-encoding inside 257 q-components, r-components, and f-components. 259 The following sections provide additional information about the 260 syntactic elements of URNs. 262 3.1. Namespace Identifier 264 The syntax here is slightly more restrictive than what was defined in 265 [RFC2141], because it prohibits the character "-" at the end of a 266 NID. 268 Note that NIDs are case insensitive (e.g., "ISBN" and "isbn" are 269 equivalent). 271 Characters outside the ASCII range [RFC20] are not permitted in NIDs, 272 and no encoding mechanism for such characters is supported. 274 3.2. Namespace Specific String 276 The namespace specific string (NSS) is a unique identifier that is 277 assigned and managed in a consistent way and that conforms to the 278 definition of the relevant namespace. The combination of the NID 279 (unique across the entire "urn" scheme) and the NSS (unique within 280 the namespace) ensures that the resulting URN is a globally unique 281 URI. 283 This document modifies the syntax of the NSS to allow the following 284 characters: "/", "~", and "&". In particular, allowing the "/" 285 character effectively makes it possible to encapsulate hierarchical 286 identifiers from other naming systems. For instance, consider the 287 hypothetical example of a hierarchical naming system in which the 288 identifiers take the form of a series of numbers separated by the "/" 289 character, such as "1/406/47452/2". If the naming authority for such 290 identifiers were to use URNs, it would be natural to place the 291 existing identifiers in the NSS, resulting in URNs such as 292 "urn:example:1/406/47452/2". 294 However, the foregoing changes to the syntax for the NSS do not 295 modify the encoding rules for URN namespaces that were defined in 296 accordance with [RFC2141]. If any such URN namespace that is used 297 outside of the URN context (i.e., as a standalone identifier space) 298 also allows the use of "/", "~", or "&" in the native form within 299 that identifier space, then the encoding rules for that namespace are 300 not changed by this specification. 302 Depending on the rules governing a namespace, names that are valid in 303 a namespace might contain characters that are not allowed by the 304 "pchar" production referenced above (e.g., characters outside the 305 ASCII range or, consistent with the restrictions in RFC 3986, the 306 characters "/", "?", "#", "[", and "]"). While such a string might 307 be a valid name, it is not a valid URN until it has been translated 308 into a conformant NSS. In the case of URNs that are formed from 309 names that exist separately in a standalone identifier space, 310 translation of an identifier from its "native" format to URN format 311 is accomplished by using the canonicalization and encoding methods 312 defined for that URN namespace. Software that is not aware of those 313 namespace-specific canonicalization and encoding rules MUST NOT 314 construct URNs from the names in the standalone identifier space. 316 In order to make URNs as stable and persistent as possible when 317 protocols evolve and the environment around them changes, namespaces 318 SHOULD NOT allow characters outside the basic Latin repertoire 319 [RFC20] unless the nature of the particular namespace makes such 320 characters necessary. 322 3.3. Optional Components 324 As compared to [RFC2141], this document extends the URN syntax to 325 permit inclusion of three new types of components: q-component, 326 r-component, and f-component. Because this specification focuses 327 almost exclusively on URN syntax, it does not define detailed 328 semantics for these components for URNs in general. However, each of 329 these components has a distinct role, which is independent of the URN 330 and its namespace, and it is intended that clients will be able to 331 handle these components uniformly for all URNs. In general: 333 o The q-component is intended for parameters to be transmitted to 334 the named resource and interpreted by that resource. 336 o The r-component is intended for parameters to be transmitted to 337 resolution services and interpreted by those services. 339 o The f-component is intended to be interpreted by the client as a 340 specification for a location within, or region of, the named 341 resource. 343 The foregoing generalizations are true regardless of the URN's 344 namespace. 346 Whenever a URN resolves to a URL which may be used to access the 347 resource, there is a more specific interpretation of q-component and 348 f-component: the q-component is copied verbatim to the query portion 349 of the URL (if that URL scheme supports query), and the f-component 350 is copied verbatim to the fragment portion of the URL. This is 351 necessary, among other reasons, so that interpretation of q-component 352 and f-component, when associated with URNs, will be consistent with 353 the interpretation of relative references containing queries or 354 fragments within documents which are ultimately accessible via URNs. 355 Thus, for URNs which may be resolved to a URL, the semantics of 356 q-component are identical to those for queries to that resource and 357 the semantics of f-components are identical to those of fragments for 358 that resource. The semantics of q-component and f-component for URNs 359 that inherently cannot be resolved to a URL (i.e., for abstract 360 designators) are undefined by this document; however, they SHOULD be 361 consistent with the above roles. It is expected that additional 362 specifications will define the semantics of r-components. 364 Note: In general, neither the syntax nor the semantics of 365 q-components or f-components are defined by, or dependent on, the 366 namespace of the URN. A particular namespace might, however, define 367 uses of r-components that are specific to its namespace and supported 368 by the resolution services which that namespace operates or 369 recommends. 371 Any of these components MAY be used with URNs from existing 372 namespaces whether or not the namespace explicitly supports them. As 373 described above, the interpretation of q-component and f-component is 374 namespace-independent. Interpretation of an r-component may be 375 namespace-dependent to some degree if it relies on behavior of a 376 namespace-specific resolution service. If a URN contains 377 r-components that are not defined by the namespace, the meaning of 378 the URN and result of resolution are out of scope for this 379 specification. 381 3.3.1. q-component 383 The URN q-component has the same syntax as the URI query component. 384 If a URN resolves to a URL with a scheme that supports a query 385 component, the q-component from the URN is copied verbatim to the 386 query component of the URL. If the URN does not resolve to a URL 387 (i.e., is an abstract designator), the interpretation of the 388 q-component is undefined by this specification. 390 The q-component is indicated by the first question mark ("?") 391 character and terminated by a double question mark ("??") indicating 392 an r-component, by a number sign ("#") character indicating an 393 f-component, or by the end of the URI. The characters slash ("/") 394 and question mark ("?") may represent data within the q-component. 395 Note that characters outside the ASCII range [RFC20] MUST be percent- 396 encoded using the method defined in Section 2.1 of the generic URI 397 specification [RFC3986]. 399 As described under Section 4, the q-component SHALL NOT be taken into 400 account when determining URN equivalence. 402 Similarly, the q-component SHALL NOT be taken into account when 403 resolving a URN to a URL and MUST NOT be used to communicate 404 parameters to a resolution service. 406 Consider the hypothetical example of passing parameters to an 407 application that returns weather reports from different regions and/ 408 or for different time periods. This could perhaps be accomplished by 409 specifying lat/long coordinates and datetimes in the URN's 410 q-component, resulting in URNs such as the following. 412 urn:example:weather?op=map&lat=39.56&lon=-104.85&datetime=1969-07-21T 413 02:56:15Z 415 However, this primary purpose is not intended to forestall other 416 potential uses for q-components for URNs that do not resolve to URLs. 418 3.3.2. r-component 420 The URN r-component has no syntactic equivalent in URIs. 422 The r-component is indicated by a double question mark ("??") and 423 terminated by a number sign ("#") character indicating an f-component 424 or by the end of the URI. The characters slash ("/") and question 425 mark ("?") may represent data within the r-component. Note that 426 characters outside the ASCII range [RFC20] MUST be percent-encoded 427 using the method defined in Section 2.1 of the generic URI 428 specification [RFC3986]. 430 As described under Section 4, the r-component SHALL NOT be taken into 431 account when determining URN equivalence. 433 However, the r-component SHALL be supplied along with the URN when 434 presenting a request to a URN resolution service. 436 The r-component is entirely intended for passing information in 437 requests to URN resolution services. The r-component is not intended 438 for passing information to the resources identified by a URN or to 439 applications that manage such resources, since that is the function 440 of the q-component. In addition, the r-component is not intended for 441 passing information to any underlying services that might exist 442 behind a resolver, only to the resolver itself. 444 This document defines only the syntax of the r-component and reserves 445 it for future use. The exact semantics of the r-component and its 446 use in URN resolution protocols are a matter for potential 447 standardization in separate specifications. 449 Consider the hypothetical example of passing parameters to resolution 450 service (say, an ISO alpha-2 country code [ISO3166-1] in order to 451 scope down the preferred country in which to search for a physical 452 copy of a book). This could perhaps be accomplished by specifying 453 the country code in the r-component, resulting in URNs such as: 455 urn:example:foo-bar-baz-qux??cc=uk 457 However, this primary purpose is not intended to forestall other 458 potential uses for r-components. 460 3.3.3. f-component 462 The URN f-component has the same syntax as the URI fragment 463 component. When a URN containing an f-component resolves to a URL, 464 the f-component from the URN is copied verbatim into the fragment of 465 that URL. If the URN does not resolve to a URL (i.e., is an abstract 466 designator), the interpretation of the f-component is undefined by 467 this specification. 469 The f-component is indicated by the presence of a number sign ("#") 470 character and terminated by the end of the URI. Note that characters 471 outside the ASCII range [RFC20] MUST be percent-encoded using the 472 method defined in Section 2.1 of the generic URI specification 473 [RFC3986]. 475 As described under Section 4, the f-component SHALL NOT be taken into 476 account when determining URN equivalence. 478 Similarly, the f-component MUST NOT be passed to resolution servers 479 when querying them for resource locations or metadata. 481 The f-component is primarily intended to distinguish the constituent 482 parts of resources named by URNs. Thus, for URNs that resolve to 483 URLs, the semantics of an f-component are defined by the media type 484 of those resources, not by the namespace. 486 Consider the hypothetical example of obtaining resources that are 487 part of a larger entity (say, the chapters of a book). Each part 488 could be specified in the f-component, resulting in URNs such as: 490 urn:example:foo-bar-baz-qux#somepart 492 However, this primary purpose is not intended to forestall other 493 potential uses for f-components for URNs that do not resolve to URLs. 495 4. Equivalence of URNs 497 4.1. Procedure 499 For various purposes such as caching, often it is desirable to 500 determine if two URNs are "the same". This is done by testing for 501 equivalence (see Section 6.1 of [RFC3986]). 503 The generic URI specification [RFC3986] is very flexible about 504 equality comparisons, putting the focus on allowing false negatives 505 and avoiding false positives. If comparisons are made in a scheme- 506 independent way, i.e., as URI comparisons only, URNs that this 507 specification considers equal would be rejected. The discussion 508 below applies when the URIs involved are known to be URNs. 510 Two URNs are equivalent if their portions are octet- 511 by-octet equal after applying case normalization (as specified in 512 Section 6.2.2.1 of [RFC3986]) to the following constructs: 514 1. the URI scheme "urn", by conversion to lower case 516 2. the NID, by conversion to lower case 518 3. any percent-encoded characters in the NSS (that is, all character 519 triplets that match the production found in 520 Section 2.1 of the base URI specification [RFC3986]), by 521 conversion to upper case for the digits A-F. 523 Percent-encoded characters MUST NOT be decoded, i.e., percent- 524 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 525 MUST NOT be applied. 527 If a q-component, r-component, or f-component (or any combination 528 thereof) are included in a URN, they MUST be ignored for purposes of 529 determining equivalence. 531 URN namespace definitions MAY include additional rules for 532 equivalence, such as case-insensitivity of the NSS (or parts 533 thereof). Such rules MUST always have the effect of eliminating some 534 of the false negatives obtained by the procedure above and MUST NOT 535 result in treating two URNs as not equivalent if the procedure here 536 says they are equivalent. For related considerations with regard to 537 NID registration, see below. 539 4.2. Examples 541 This section shows a variety of URNs (using the "example" NID defined 542 in [RFC6963]) that highlight the equivalence rules. 544 First, because the scheme and NID are case-insensitive, the following 545 URNs are equivalent to each other: 547 o urn:example:a123,z456 549 o URN:example:a123,z456 551 o urn:EXAMPLE:a123,z456 553 Second, because the q-component and f-component are not taken into 554 account for purposes of testing equivalence, the following URNs are 555 equivalent to the first three examples above: 557 o urn:example:a123,z456?abc 559 o urn:example:a123,z456#789 561 o urn:example:a123,z456#abc 563 Third, because the "/" character (and anything that follows it) in 564 the NSS is taken into account for purposes of equivalence, the 565 following URNs are not equivalent to each other or to the preceding 566 URNs: 568 o urn:example:a123,z456/foo 570 o urn:example:a123,z456/bar 572 o urn:example:a123,z456/baz 574 Fourth, because of percent-encoding, the following URNs are 575 equivalent only to each other (although %2C is the percent-encoded 576 transformation of "," from the previous examples, such sequences are 577 not decoded for purposes of testing equivalence): 579 o urn:example:a123%2Cz456 581 o URN:EXAMPLE:a123%2cz456 583 Fifth, because characters other than percent-encoded sequences in the 584 NSS are treated in a case-sensitive manner (unless otherwise 585 specified for the namespace in question), the following URNs are not 586 equivalent to the first three URNs: 588 o urn:example:A123,z456 590 o urn:example:a123,Z456 592 Sixth, on casual visual inspection of a URN presented in a human- 593 oriented interface the following URN might appear the same as the 594 first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be 595 confused with U+0061 LATIN SMALL LETTER A), but it is not equivalent: 597 o urn:example:%D0%B0123,z456 599 5. URI Conformance 601 5.1. Use in URI Protocol Slots 603 Because a URN is, syntactically, a URI under the "urn" scheme, in 604 theory a URN can be placed in any protocol slot that allows for a URI 605 (e.g., the 'href' and 'src' attributes in HTML, the element 606 in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' 607 attribute in XML for XML namespace names [XML-NAMES]). 609 However, this does not imply that, semantically, it always makes 610 sense in practice to place a URN in a given URI protocol slot; in 611 particular, because a URN might not specify the location of a 612 resource or even point indirectly to one, it might not be appropriate 613 to place a URN in a URI protocol slot that points to a resource 614 (e.g., the aforementioned 'href' and 'src' attributes). 616 Ultimately, guidelines regarding when it is appropriate to use URIs 617 under the "urn" scheme (or any other scheme) are the responsibility 618 of specifications for individual URI protocol slots (e.g., the 619 specification for the 'xml:base' attribute in XML might recommend 620 that it is inappropriate to use URNs in that protocol slot). This 621 specification cannot possibly anticipate all of the relevant cases, 622 and it is not the place of this specification to require or restrict 623 usage for individual protocol slots. 625 5.2. Parsing 627 In part because of the separation of semantics from syntax 628 [I-D.ietf-urnbis-semantics-clarif], generic URI processors need to 629 pay special attention to the parsing and analysis rules of RFC 3986 630 and, in particular, must treat the URI as opaque unless the scheme 631 and its requirements are recognized, in which case they may be in a 632 position to invoke scheme-appropriate processing such as by a URN 633 resolver. The URN resolver can either be an external resolver that 634 the URI resolver knows of, or it can be functionality built into the 635 URI resolver. Note that this requirement might impose constraints on 636 the contexts in which URNs are appropriately used; see Section 5.1. 638 5.3. URNs and Relative References 640 [RFC3986] Section 5.2 describes an algorithm for converting a URI 641 reference that might be relative to a given base URI into "parsed 642 components" of the target of that reference, which can then be 643 recomposed per RFC 3986 Section 5.3 into a target URI. This 644 algorithm cannot be applied directly to URNs because their syntax 645 does not support the necessary path components. The notion of a URN 646 as a "persistent", "permanent" identifier does not reconcile easily 647 with relative referencing. However, resources named with URNs may 648 contain relative references that do not apply to the URN itself. 650 Therefore a relative reference SHOULD NOT be evaluated directly with 651 respect to a URN. Instead, a relative reference SHOULD be evaluated 652 indirectly with respect to one of the following: 654 1. a base URI (other than a URN) declared by the resource itself; or 656 2. a base URI (other than a URN) obtained through the URN resolution 657 process; or 659 3. the URL of the resource as obtained through the URN resolution 660 process 662 (Case 2 permits the resolution process to explicitly supply a base 663 URI if the resource content is supplied directly by the resolution 664 service rather than via an intermediate "location" URI.) 666 If no such base URI exists, use of a relative reference with respect 667 to a URN is an error. Client behavior in this case is undefined. 669 Resolution services SHOULD ensure that a base URI is supplied any 670 time they provide resource content directly to a client. 672 5.4. Transport and Display 674 When URNs are transported and exchanged, they MUST be represented in 675 the format defined herein. Further, all URN-aware applications MUST 676 offer the option of displaying URNs in this canonical form to allow 677 for direct transcription (for example by cut and paste techniques). 678 Such applications might support display of URNs in a more human- 679 friendly form and might use a character set that includes characters 680 that are not permitted in URN syntax as defined in this specification 681 (e.g., when displaying URNs to humans, such applications might 682 replace percent-encoded strings with characters from an extended 683 character repertoire such as Unicode [UNICODE]). 685 To minimize user confusion, a URI browser SHOULD display the complete 686 URN (including the "urn" scheme and any components) to ensure that 687 there is no confusion between URN namespace identifiers and URI 688 scheme identifiers. For example, a URI beginning with "urn:xmpp:" 689 [RFC4854] is very different from a URI beginning with "xmpp:" 690 [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] is 691 different from, and possibly completely unrelated to, a possible DOI 692 URN namespace. 694 5.5. URI Design and Ownership 696 As mentioned, the assignment of URNs is a managed process, as is the 697 assignment of namespaces themselves. Although design of the URNs to 698 be assigned within a given namespace is ceded by this specification 699 to the namespace owner, doing so in a managed way avoids the problems 700 inherent in unmanaged generation of URIs as described in the 701 recommendations regarding URI design and ownership [RFC7320]. 703 6. URN Namespaces 705 A URN namespace is a collection of identifiers that obey three 706 constraints: each identifier is (1) unique, (2) assigned in a 707 consistent way, and (3) assigned according to a common definition. 709 1. The "uniqueness" constraint means that an identifier within the 710 namespace is never assigned to more than one resource and never 711 reassigned to a different resource (for the kind of "resource" 712 identified by URNs assigned within the namespace). This holds 713 true even if the identifier itself is deprecated or becomes 714 obsolete. 716 2. The "consistent assignment" constraint means that an identifier 717 within the namespace is assigned by an organization or created in 718 accordance with a process or algorithm that is always followed. 720 3. The "common definition" constraint means that there are clear 721 definitions for the syntax of identifiers within the namespace 722 and for the process of assigning or creating them. 724 A URN namespace is identified by a particular NID in order to ensure 725 the global uniqueness of URNs and, optionally, to provide a cue 726 regarding the structure of URNs assigned within a namespace. 728 With regard to global uniqueness, using different NIDs for different 729 collections of identifiers ensures that no two URNs will be the same 730 for different resources, since each collection is required to 731 uniquely assign each identifier. However, a single resource MAY have 732 more than one URN assigned to it, either in the same namespace (if 733 the namespace permits it) or in different namespaces, and either for 734 similar purposes or different purposes. (For example, if a book were 735 published in a monograph series, it could have both an ISBN [RFC3187] 736 and an ISSN [RFC3044] assigned to it, resulting in two URNs referring 737 to the same book.) Subject to other constraints, such as those 738 imposed by the URI syntax [RFC3986], the rules of the URN scheme are 739 intended to allow preserving the normal and natural form of 740 identifiers specified elsewhere when they are treated as URN 741 namespaces. 743 With regard to the structure of URNs assigned within a namespace, the 744 development of an identifier structure (and thereby a collection of 745 identifiers) depends on the requirements of the community defining 746 the identifiers, how the identifiers will be assigned and used, etc. 747 These issues are beyond the scope of URN syntax and the general rules 748 for URN namespaces, because they are specific to the community 749 defining a namespace (e.g., the bibliographic and publishing 750 communities in the case of the 'ISBN' and 'ISSN' namespaces, or the 751 developers of extensions to the Extensible Messaging and Presence 752 Protocol in the case of the 'XMPP' namespace). 754 URN namespaces inherit certain rights and responsibilities by the 755 nature of URNs, e.g.: 757 1. They uphold the general principles of a well-managed URN 758 namespace by providing persistent identification of resources and 759 unique assignment of identifier strings in accordance with a 760 common definition. 762 2. Optionally, they can be registered in global registration 763 services. 765 There are two types of URN namespace: formal and informal. These are 766 distinguished by the expected level of service, the information 767 needed to define the namespace, and the procedures for registration. 769 Because the majority of the namespaces registered so far have been 770 formal, this document concentrates on formal namespaces. 772 Note: [RFC3406] defined a third type of "experimental namespaces", 773 denoted by prefixing the namespace identifier with the string "X-". 774 Consistent with general IETF conclusions about similar approaches 775 [RFC6648], this specification removes the experimental category and 776 syntax. Because experimental namespaces were never registered, 777 removing the experimental category has no impact on the existing 778 registries. However, to avoid the potential for conflict between 779 previously-allowed unregistered experimental namespaces and 780 namespaces registered in the future, no registrations will be 781 accepted for new namespaces beginning with "X-". Because they are 782 not registered, strings that refer to experimental namespaces are not 783 valid URNs. Truly experimental usages MAY, of course, employ the 784 'example' namespace [RFC6963]. 786 6.1. Formal Namespaces 788 A formal namespace provides benefit to some subset of users on the 789 Internet. In particular, it would not make sense for a formal 790 namespace to be used only by a community or network that is not 791 connected to the Internet. For example, it would be inappropriate 792 for a NID to effectively force someone to use a proprietary network 793 or service not open to the general Internet user. The intent is 794 that, while the community of those who might actively use the names 795 assigned within that NID might be small, the potential use of 796 identifiers within that NID is open to any user on the Internet. 797 Formal NIDs might be appropriate even when some aspects are not fully 798 open. For example, a namespace might make use of a fee-based, 799 privately managed, or proprietary registry for assignment of URNs in 800 the namespace. However, it might still benefit some Internet users 801 if the associated services have openly-published identifiers. 803 An organization that will assign URNs within a formal namespace 804 SHOULD meet the following criteria: 806 1. Organizational stability and the ability to maintain the URN 807 namespace for a long time; absent such evidence, it ought to be 808 clear how the namespace can remain viable if the organization can 809 no longer maintain the namespace. 811 2. Competency in name assignment. This will improve the likelihood 812 of persistence (e.g. to minimize the likelihood of conflicts). 814 3. Commitment to not reassigning existing names and to allowing old 815 names to continue to be valid (e.g., if the assignee of a name is 816 no longer a member or customer of the assigning organization, if 817 various information about the assignee or named entity happens to 818 change, or even if the assignee or the named entity itself is no 819 longer in existence; in all these cases, the name is still 820 valid). 822 A formal namespace establishes a particular NID, subject to the 823 following constraints (above and beyond the syntax rules already 824 specified): 826 1. It MUST NOT be an already-registered NID. 828 2. It MUST NOT start with "urn-" (which is reserved for informal 829 namespaces). 831 3. It MUST be more than two characters long. 833 4. It MUST NOT start with "aa-", where "aa" is any combination of 834 two ASCII letters and the hyphen is followed by something other 835 than another hyphen. 837 5. It MUST NOT start with the string "xn--" or any other string 838 consisting of two letters followed by two hyphens. Those strings 839 are reserved for potential representation of DNS A-labels and 840 similar strings in the future [RFC5890]. 842 6. It MUST NOT start with the string "X-" so that it will not be 843 confused with or conflict any experimental namespace previously 844 permitted by [RFC3406]. 846 All two-letter strings, and all two-letter strings followed by "-" 847 and any sequence of valid NID characters, are reserved for potential 848 use as NIDs based on ISO alpha-2 country codes [ISO3166-1] for 849 eventual national registrations of URN namespaces. The definition 850 and scoping of rules for allocation of responsibility for such 851 country-code-based namespaces is beyond the scope of this document. 853 Applicants and reviewers considering new NIDs should also be aware 854 that they may be considered as names with semantic implications and 855 hence a source of conflict. Particular attention should be paid to 856 strings that might be construed as names of, or registered under the 857 authority of, countries (including ISO 3166-1 alpha-3 codes) and to 858 strings that might imply association with existing URI schemes, 859 identifier systems, or trademarks. However, in line with traditional 860 policies, disputes about "ownership" of particular strings are 861 disagreements among the parties involved; neither IANA nor the IETF 862 will become involved in such disputes except in response to orders 863 from a court of competent jurisdiction. 865 6.2. Informal Namespaces 867 Informal namespaces are full-fledged URN namespaces, with all the 868 associated rights and responsibilities. Informal namespaces differ 869 from formal namespaces in the process for assigning a NID: for an 870 informal namespace, the registrant does not designate the NID; 871 instead, IANA assigns a NID consisting of the string 'urn-' followed 872 by one or more digits (e.g., "urn-7") where the digits consist of the 873 next available number in the sequence of positive integers assigned 874 to informal namespaces. Thus the syntax of an informal namespace is: 876 InformalNamespaceName = "urn-" Number 877 Number = DigitNonZero 0*Digit 878 DigitNonZero = "1"/ "2" / "3" / "4"/ "5" 879 / "6" / "7" / "8" / "9" 880 Digit = "0" / DigitNonZero 882 The only restrictions on are that it (1) consist strictly of 883 ASCII digits, that it (2) not have leading zeros, and that it (3) not 884 cause the NID to exceed the length limitations defined for the URN 885 syntax. 887 7. Defining and Registering a URN Namespace 889 7.1. Overview 891 Because the space of URN namespaces is itself managed, the definition 892 of a namespace SHOULD pay particular attention to: 894 1. The purpose of the namespace. 896 2. The syntax of URNs assigned within the namespace, including 897 whether q-components, r-components, or f-components are allowed. 899 3. The process for assigning URNs within the namespace. 901 4. The security implications of assigning URNs within the namespace 902 and using the assigned URNs. 904 5. Any potential interoperability issues with URNs assigned within 905 the namespace. 907 6. Optionally, the process for resolving URNs issued within the 908 namespace. 910 The section on completing the template (Section 7.3) explains these 911 matters in greater detail. 913 7.2. Registration Policy and Process 915 The basic registration policy for URN namespaces is Expert Review as 916 defined in the "IANA Considerations" document [RFC5226]. For 917 namespaces or their definitions that are intended to become standards 918 or normative components of standards, the output of the Expert Review 919 process is intended to be a report, rather than instructions to IANA 920 to take action (see below). The key steps are: 922 1. Fill out the namespace registration template (see Section 7.3 and 923 Appendix A). This can be done as part of an Internet-Draft or a 924 specification in another series, although that is not necessary. 926 2. Send the completed template to the urn@ietf.org discussion list 927 for review. 929 3. If necessary to address comments received, repeat steps 1 and 2. 931 4. If the designated experts approve the request and no 932 standardization action is involved, the IANA will register the 933 requested NID. If standardization is anticipated, the designated 934 experts will prepare a report and forward it to the appropriate 935 standards approval body (the IESG in the case of the IETF) and 936 IANA will register the requested NID only after receiving 937 directions from that body and a copy of the expert review report. 939 A namespace registration can be revised by updating the registration 940 template, following the same steps outlined above for new 941 registrations. A revised registration MUST describe differences from 942 prior versions and SHOULD make special note of any relevant changes 943 in the underlying technologies or namespace management processes. 945 Experience to date with namespace registration requests has shown 946 that registrants sometimes do not initially understand some of the 947 subtleties of URN namespaces, and that defining the namespace in the 948 form of a specification enables the registrants to clearly formulate 949 their "contract" with the intended user community. Therefore, 950 although the registration policy for formal namespaces is Expert 951 Review and a specification is not strictly required, it is 952 RECOMMENDED for registrants to provide a stable specification 953 documenting the namespace definition and expanding upon the issues 954 described herein. 956 Because naming can be difficult and contentious, namespace 957 registrants and the designated experts are strongly encouraged to 958 work together in a spirit of good faith and mutual understanding to 959 achieve rough consensus (see [RFC7282]) on handling registration 960 requests. They are also encouraged to bring additional expertise 961 into the discussion if that would be helpful in providing perspective 962 or otherwise resolving issues. 964 Especially when iterations in the registration process are prolonged, 965 designated experts are expected to take reasonable precautions to 966 avoid race conditions on proposed NID names and, if such situations 967 arise, to encourage applicants to work out any conflicts among 968 themselves. 970 7.3. Completing the Template 972 A template for defining and registering a URN namespace is provided 973 in Appendix A. This section describes considerations for completing 974 the template. 976 7.3.1. Purpose 978 The "Purpose" section of the template describes matters such as: 980 1. The kinds of resources identified by URNs assigned within the 981 namespace. 983 2. The scope and applicability of the URNs assigned within the 984 namespace; this might include information about the community of 985 use (e.g., a particular nation, industry, technology, or 986 organization), whether the assigned URNs will be used on public 987 networks or private networks, etc. 989 3. How the intended community (and the Internet community at large) 990 will benefit from using or resolving the assigned URNs. 992 4. How the namespace relates to and complements existing URN 993 namespaces, URI schemes, and identifier systems. 995 5. The kinds of software applications that can use or resolve the 996 assigned URNs (e.g., by differentiating among disparate 997 namespaces, identifying resources in a persistent fashion, or 998 meaningfully resolving and accessing services associated with the 999 namespace). 1001 6. Whether resolution services are available or will be available 1002 (and, if so, the nature or identity of the services). Examples 1003 of q- and r-component semantics and syntax are helpful here, even 1004 if they are registered or defined elsewhere later. 1006 7. Whether the namespace or its definition are expected to become an 1007 integral or normative element of a standard being developed in 1008 the IETF or some other recognized standards body. 1010 7.3.2. Syntax 1012 The "Syntax" section of the template contains: 1014 1. A description of the structure of URNs within the namespace, in 1015 conformance with the fundamental URN syntax. The structure might 1016 be described in terms of a formal definition (e.g., using 1017 Augmented BNF for Syntax Specifications (ABNF) as specified in 1018 [RFC5234]), an algorithm for generating conformant URNs, or a 1019 regular expression for parsing the identifier into components; 1020 alternatively, the structure might be opaque. 1022 2. Any special character encoding rules for assigned URNs (e.g., 1023 which character ought to always be used for quotes). 1025 3. Rules for determining equivalence between two identifiers in the 1026 namespace. Such rules ought to always have the effect of 1027 eliminating false negatives that might otherwise result from 1028 comparison. If it is appropriate and helpful, reference can be 1029 made to specific equivalence rules defined in the URI 1030 specification [RFC3986]. Examples of equivalence rules include 1031 equivalence between uppercase and lowercase characters in the 1032 Namespace Specific String, between hyphenated and non-hyphenated 1033 groupings in the identifier string, or between single-quotes and 1034 double-quotes. (Note that these are not normative statements for 1035 any kind of best practice related to handling of equivalences 1036 between characters in general; they are statements limited to one 1037 particular namespace only.) 1039 4. Any special considerations necessary for conforming with the URN 1040 syntax. This is particularly applicable in the case of existing 1041 naming systems that are used in the context of URNs. For 1042 example, if a namespace is used in contexts other than URNs, it 1043 might make use of characters that are reserved in the URN syntax. 1044 This section ought to note any such characters, and outline 1045 necessary mappings to conform to URN syntax. Normally, this will 1046 be handled by percent-encoding the character as specified in 1047 Section 2.1 of the URI specification [RFC3986]. 1049 7.3.3. Assignment 1051 The "Assignment" section of the template describes matters such as: 1053 1. Mechanisms or authorities for assigning URNs to resources. It 1054 ought to make clear whether assignment is completely open (e.g., 1055 following a particular procedure such as first-come, first-served 1056 (FCFS)), completely closed (e.g., for a private organization), or 1057 limited in various ways (e.g., delegated to authorities 1058 recognized by a particular organization); if limited, it ought to 1059 explain how to become an assigner of identifiers or how to 1060 request assignment of identifiers from existing assignment 1061 authorities. 1063 2. Methods for ensuring that URNs within the namespace are unique. 1064 For example, identifiers might be assigned sequentially or in 1065 accordance with some well-defined process by a single authority, 1066 assignment might be partitioned among delegated authorities that 1067 are individually responsible for respecting uniqueness rules, or 1068 URNs might be created independently following an algorithm that 1069 itself guarantees uniqueness. 1071 7.3.4. Security and Privacy 1073 The "Security and Privacy" section of the template describes any 1074 potential issues related to security and privacy with regard to 1075 assignment, use, and resolution of identifiers within the namespace. 1076 Examples of such issues include: 1078 o The consequences of producing false negatives and false positives 1079 during comparison for equivalence (see "Issues in Identifier 1080 Comparison for Security Purposes" [RFC6943]) 1082 o Leakage of private information when identifiers are communicated 1083 on the public Internet 1085 o The potential for directory harvesting 1087 o Various issues discussed in the guidelines for security 1088 considerations in RFCs [RFC3552] and the privacy considerations 1089 for Internet protocols [RFC6973]. 1091 7.3.5. Interoperability 1093 The "Interoperability" section MUST specify any potential issues 1094 related to interoperability. Examples include possible confusion 1095 with other URN namespaces or naming systems because of syntax (e.g., 1096 percent-encoding of certain characters) or scope (e.g., overlapping 1097 areas of interest). If at all possible, concerns that arise during 1098 the registration of a URN namespace (e.g., due to the syntax or scope 1099 of an identifier system) SHOULD be resolved as part of the 1100 registration process. 1102 7.3.6. Resolution 1104 The "Resolution" section MUST specify whether resolution mechanisms 1105 are intended or anticipated for URNs assigned within the namespace 1106 (e.g., URNs within some namespaces are intended to act as abstract 1107 designators and thus are not intended to be resolved). 1109 If resolution is intended, then this section SHOULD specify whether 1110 the organization that assigns URNs within the namespace intends to 1111 operate or recommend any resolution services for URNs within that 1112 namespace. In addition, if the assigning organization intends to 1113 implement registration for publicly advertised resolution services 1114 (for example using a system based on principles similar to those 1115 described in [RFC2276] and [RFC2483]), then this section SHOULD list 1116 or reference the requirements for being publicly advertised by the 1117 assigning organization. 1119 8. IANA Considerations 1121 8.1. URI Scheme 1123 This section updates the registration of the 'urn' URI scheme in the 1124 Permanent URI Registry [URI-Registry] . 1126 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 1127 and the number assigned to this document upon publication.] 1129 URI Scheme Name: urn 1131 Status: permanent 1133 URI Scheme Syntax: See Section 3 of [ this document ]. 1135 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 1136 Names, which are persistent, location-independent resource 1137 identifiers. 1139 Encoding Considerations: See Section 3 of [ this document ]. 1141 Applications/Protocols That Use This URI Scheme Name: Uniform 1142 Resource Names are used in a wide variety of applications, 1143 including bibliographic reference systems and as names for 1144 Extensible Markup Language (XML) namespaces. 1146 Interoperability Considerations: See Section 5 of [ this document ]. 1148 Security Considerations: See Section 7.3.4 and Section 9 of [ this 1149 document ]. 1151 Contact: URNBIS WG [mailto:urn@ietf.org] 1153 Author/Change Controller: This scheme is registered under the IETF 1154 tree. As such, the IETF maintains change control. 1156 References None. 1158 8.2. Registration of URN Namespaces 1160 This document outlines the processes for registering URN namespaces, 1161 and has implications for the IANA in terms of registries to be 1162 maintained (see especially Section 7). In all cases, the IANA ought 1163 to assign the appropriate NID (formal or informal) once the 1164 procedures outlined in this document have been completed. 1166 9. Security and Privacy Considerations 1168 The definition of a URN namespace needs to account for potential 1169 security and privacy issues related to assignment, use, and 1170 resolution of identifiers within the namespace (e.g., some namespace 1171 resolvers might assign special meaning to certain characters in the 1172 Namespace Specific String); see Section 7.3.4 for further discussion. 1174 In most cases, URN namespaces provide a way to declare public 1175 information. Nominally, these declarations will have a relatively 1176 low security profile, however there is always the danger of 1177 "spoofing" and providing misinformation. Information in these 1178 declarations ought to be taken as advisory. 1180 10. References 1182 10.1. Normative References 1184 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 1185 October 1969. 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, March 1997. 1190 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1191 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1192 3986, January 2005. 1194 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1195 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1196 May 2008. 1198 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1199 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1201 10.2. Informative References 1203 [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The 1204 "doi" URI Scheme for the Digital Object Identifier (DOI)", 1205 June 2003, 1206 . 1208 [I-D.ietf-urnbis-semantics-clarif] 1209 Klensin, J., "URN Semantics Clarification", draft-ietf- 1210 urnbis-semantics-clarif-02 (work in progress), August 1211 2015. 1213 [ISO3166-1] 1214 ISO, "Codes for the representation of names of countries 1215 and their subdivisions -- Part 1: Country codes", ISO 1216 3166-1:2013, 2013. 1218 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1219 Uniform Resource Names", RFC 1737, December 1994. 1221 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1223 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1224 Name Resolution", RFC 2276, January 1998. 1226 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1227 Necessary for URN Resolution", RFC 2483, January 1999. 1229 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1230 Standard Number) as URN (Uniform Resource Names) within an 1231 ISSN-URN Namespace", RFC 3044, January 2001. 1233 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1234 Book Numbers as Uniform Resource Names", RFC 3187, October 1235 2001. 1237 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1238 "Uniform Resource Names (URN) Namespace Definition 1239 Mechanisms", BCP 66, RFC 3406, October 2002. 1241 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1242 Text on Security Considerations", BCP 72, RFC 3552, July 1243 2003. 1245 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1246 for Extensions to the Extensible Messaging and Presence 1247 Protocol (XMPP)", RFC 4854, April 2007. 1249 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1250 (IRIs) and Uniform Resource Identifiers (URIs) for the 1251 Extensible Messaging and Presence Protocol (XMPP)", RFC 1252 5122, February 2008. 1254 [RFC5890] Klensin, J., "Internationalized Domain Names for 1255 Applications (IDNA): Definitions and Document Framework", 1256 RFC 5890, August 2010. 1258 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1259 "Deprecating the "X-" Prefix and Similar Constructs in 1260 Application Protocols", BCP 178, RFC 6648, June 2012. 1262 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1263 Purposes", RFC 6943, May 2013. 1265 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1266 for Examples", BCP 183, RFC 6963, May 2013. 1268 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1269 Morris, J., Hansen, M., and R. Smith, "Privacy 1270 Considerations for Internet Protocols", RFC 6973, July 1271 2013. 1273 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 1274 7282, June 2014. 1276 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1277 7320, July 2014. 1279 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-, 1280 . 1282 [URI-Registry] 1283 IANA, "Permanent URI Schemes", . 1286 [XML-BASE] 1287 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1288 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1289 January 2009, 1290 . 1292 [XML-NAMES] 1293 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1294 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1295 Web Consortium Recommendation REC-xml-names-20091208, 1296 December 2009, 1297 . 1299 Appendix A. Registration Template 1301 Namespace ID: Requested of IANA (formal) or assigned by IANA 1302 (informal). 1304 Version: The version of the registration, starting with 1 and 1305 incrementing by 1 with each new version. 1307 Date: The date when the registration is requested of IANA, using the 1308 format YYYY-MM-DD. 1310 Registrant: The person or organization that has registered the NID, 1311 including the name and address of the registering organization, as 1312 well as the name and contact information (email, phone number, or 1313 postal address) of the designated contact person. 1315 Purpose: Described under Section 7.3.1 of this document. 1317 Syntax: Described under Section 7.3.2 of this document. Unless the 1318 registration explicitly says otherwise, use of q-components and 1319 f-components is not allowed for this namespace. 1321 Assignment: Described under Section 7.3.3 of this document. 1323 Security and Privacy: Described under Section 7.3.4 of this 1324 document. 1326 Interoperability: Described under Section 7.3.5 of this document. 1328 Resolution: Described under Section 7.3.6 of this document. 1330 Documentation A pointer to an RFC, a specification published by 1331 another standards development organization, or another stable 1332 document that provides further information about the namespace. 1334 Revision Information: Description of changes from prior version(s). 1335 (Applicable only when earlier registrations have been revised.) 1337 Appendix B. Changes from RFC 2141 1339 This document makes the following substantive changes from [RFC2141]: 1341 o Formally registers 'urn' as a URI scheme. 1343 o Disallows "-" at the end of a NID. 1345 o Allows the "/", "~", and "&" characters in the namespace-specific 1346 string (NSS). 1348 o Allows q-components, r-components, and f-components. 1350 Appendix C. Changes from RFC 3406 1352 This document makes the following substantive changes from [RFC3406]: 1354 1. Relaxes the registration policy for formal namespaces from "IETF 1355 Review" to "Expert Review" as discussed in Section 7.2. 1357 2. Removes the category of experimental namespaces, consistent with 1358 [RFC6648]. 1360 3. Simplifies the registration template. 1362 In addition, some of the text has been updated to be consistent with 1363 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1364 the processes for registering information with the IANA [RFC5226], as 1365 well as more modern guidance with regard to security [RFC3552] and 1366 privacy [RFC6973] issues and identifier comparison [RFC6943]. 1368 Appendix D. Contributors 1370 RFC 2141, which provided the basis for the syntax portion of this 1371 document, was authored by Ryan Moats. 1373 RFC 3406, which provided the basis for the namespace portion of this 1374 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1375 Renato Iannella, and Patrik Faltstrom. 1377 Their work is gratefully acknowledged. 1379 Appendix E. Acknowledgements 1381 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1382 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1383 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1384 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1385 participants in the URNBIS WG for their input. Alfred Hoenes in 1386 particular edited an earlier version of this document and served as 1387 co-chair of the URNBIS WG. 1389 Juha Hakala deserves special recognition for his dedication to 1390 successfully completing this work, as do Andrew Newton and Melinda 1391 Shore in their roles as working group co-chairs and Barry Leiba in 1392 his role as area director. 1394 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1396 [[RFC Editor: please remove this appendix before publication.]] 1398 F.1. Changes from -08 to -09 1400 o Altered the text in Section 5 to reflect list discussions about 1401 the earlier phrasing. Also added DOI example and citation to that 1402 section. 1404 o Clarified the naming rules for formal namespaces and their 1405 relationship to ISO 3166, IDNA, etc., reserved strings. 1407 o Added an explicit statement about use of URNs in various protocols 1408 and contexts to Section 5. 1410 o Clarified that experimental namespace NIDs, which were explicitly 1411 not registered, are not valid URNs (in Section 6. 1413 o Transformed the partial production in Section 6.2 into valid ABNF. 1415 o Added more text about p-/q-/f-components and recommendations about 1416 use. 1418 o Added clarifying note about "?" within q-components and 1419 f-components. 1421 o Added explicit requirement that revisions of existing 1422 registrations document the changes and added a slot for that 1423 description to the template. 1425 o Many small editorial changes and adjustments including adding 1426 additional references and cross-references for clarification. 1428 o Inserted a placeholder for additional examples. 1430 F.2. Changes from -09 to -10 1432 o Several clarifying editorial changes, most suggested by Ted Hardie 1433 and Henry S. Thompson (some of them off-list). 1435 o Added a large number of placeholders that identify issues that 1436 require WG consideration and resolution (or WG delegation to the 1437 editors). 1439 F.3. Changes from -10 to -11 1441 o Removed most of the placeholders added in -10. Supplied new text 1442 as required or suggested by on-list discussion of those issues. 1444 o Replaced the conformance examples Section 4.2 with a more complete 1445 collection and discussion. 1447 o Revised and consolidated the registration procedure, and added 1448 provisions for NIDs that are the subject of standards and for 1449 avoiding race conditions about NID strings. 1451 o In response to independent comments from Ted Hardie and Henry S. 1452 Thompson, called attention to the possibility of conflicts between 1453 NID strings and various claims of national, corporate, and other 1454 perogatives. 1456 o Changed the production for assigned-name as suggested by Lars 1457 Svensson. 1459 o Several clarifying editorial changes including correcting a glitch 1460 in instructions to the RFC Editor. 1462 F.4. Changes from -11 to -12 1464 o Removed p-components as a standalone construct, and instead folded 1465 them into the NSS. 1467 o Defined syntax for r-components as a way to pass information to 1468 resolvers, but left the semantics for future standardization 1469 efforts. 1471 o Further tuned the discussion of interoperability and related 1472 registration issues. 1474 o Made a number of editorial corrections and reorganized the syntax 1475 material in Section 3 somewhat to make it internally consistent 1476 and keep the relationship to RFC 3986 clear. 1478 F.5. Changes from -12 to -13 1480 o More precisely defined the semantics of the optional components. 1482 o Defined the term "resolution" and clarified several related 1483 matters throughout the text. 1485 o Clarified terminological relationship to RFC 3986. 1487 o Further cleansed the document of p-components. 1489 o Corrected several examples to avoid confusion with existing 1490 identifier systems. 1492 o Improved text regarding the purpose of namespaces being 1493 registered. 1495 Authors' Addresses 1497 Peter Saint-Andre 1498 &yet 1500 Email: peter@andyet.com 1501 URI: https://andyet.com/ 1503 John C Klensin 1504 1770 Massachusetts Ave, Ste 322 1505 Cambridge, MA 02140 1506 USA 1508 Phone: +1 617 245 1457 1509 Email: john-ietf@jck.com