idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-11.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 (March 31, 2015) is 3285 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'URI-Registry' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' == Outdated reference: A later version (-04) exists of draft-ietf-urnbis-semantics-clarif-01 -- 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 (==), 10 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 March 31, 2015 6 Expires: October 2, 2015 8 Uniform Resource Names (URNs) 9 draft-ietf-urnbis-rfc2141bis-urn-11 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, typically with the intent that the URN will be a 16 persistent, location-independent resource identifier or abstract 17 designator. With regard to URN syntax, this document defines the 18 canonical syntax for URNs (in a way that is consistent with URI 19 syntax), specifies methods for determining URN equivalence, and 20 discusses URI conformance. With regard to URN namespaces, this 21 document specifies a method for defining a URN namespace and 22 associating it with a namespace identifier, and describes procedures 23 for registering namespace identifiers with the Internet Assigned 24 Numbers Authority (IANA). This document obsoletes both RFC 2141 and 25 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 October 2, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Namespace Identifier Syntax . . . . . . . . . . . . . . . 5 77 3.2. Namespace Specific String Syntax . . . . . . . . . . . . 5 78 3.3. p-component, q-component, and f-component . . . . . . . . 6 79 4. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 10 83 6. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 13 85 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 15 86 7. Defining and Registering a URN Namespace . . . . . . . . . . 15 87 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.2. Registration Policy and Process . . . . . . . . . . . . . 16 89 7.3. Completing the Template . . . . . . . . . . . . . . . . . 17 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 20 92 8.2. Registration of URN Namespaces . . . . . . . . . . . . . 21 93 9. Security and Privacy Considerations . . . . . . . . . . . . . 21 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 96 10.2. Informative References . . . . . . . . . . . . . . . . . 22 98 Appendix A. Registration Template . . . . . . . . . . . . . . . 24 99 A.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . 24 100 A.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 A.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 A.4. Registrant . . . . . . . . . . . . . . . . . . . . . . . 24 103 A.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 A.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 A.7. Assignment . . . . . . . . . . . . . . . . . . . . . . . 24 106 A.8. Security and Privacy . . . . . . . . . . . . . . . . . . 25 107 A.9. Interoperability . . . . . . . . . . . . . . . . . . . . 25 108 A.10. Resolution . . . . . . . . . . . . . . . . . . . . . . . 25 109 A.11. Documentation . . . . . . . . . . . . . . . . . . . . . . 25 110 A.12. Revision Information . . . . . . . . . . . . . . . . . . 25 111 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 25 112 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 25 113 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 26 114 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 26 115 Appendix F. Change log for versions of draft-ietf-urnbis- 116 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 26 117 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 26 118 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 27 119 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 27 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 122 1. Introduction 124 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 125 [RFC3986] that is assigned under the "urn" scheme and a particular 126 namespace, typically with the intent that the URN will be a 127 persistent, location-independent resource identifier or abstract 128 designator. 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 schemes may allow identifiers to be freely chosen and 143 assigned, this is not the case for URNs. The syntactical correctness 144 of a string appearing after "urn:" is not sufficient to make it a 145 URN; both the namespace identifier and namespace specific string must 146 be registered or generated according to the rules given for it to be 147 a valid URN. 149 So that information about both URN syntax and URN namespaces is 150 available in one place, this document does the following: 152 1. Defines the canonical syntax for URNs in general (in a way that 153 is consistent with URI syntax), specifies methods for determining 154 URN equivalence, and discusses URI conformance. 156 2. Specifies a method for defining a URN namespace and associating 157 it with a namespace identifier, and describes procedures for 158 registering namespace identifiers with the Internet Assigned 159 Numbers Authority (IANA). 161 For URN syntax and URN namespaces, this document modernizes and 162 replaces the definitions from [RFC2141] and [RFC3406]. These 163 modifications build on the requirements provided in [RFC1737] and 164 many years of experience with URNs, in both cases attempting to make 165 the smallest reasonable set of changes from the previous definitions. 167 This document obsoletes both [RFC2141] and [RFC3406]. 169 2. Terminology 171 Several important terms used in this document, including some 172 "normalization" operations that are not part of the Unicode Standard, 173 are defined in the URI specification [RFC3986]. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in 178 [RFC2119]. 180 3. URN Syntax 182 The syntax of URNs as provided in [RFC2141] was defined before the 183 updated specification of URIs in [RFC3986]. To ensure consistency 184 with the URI syntax as well as semantic flexibility in the use of 185 URNs within particular applications (see 186 [I-D.ietf-urnbis-semantics-clarif] for further discussion), this 187 specification extends the syntax of URNs to explicitly allow several 188 characters (and thus URI components) that were not allowed by 189 [RFC2141], and also makes several smaller syntax adjustments. 190 However, this specification does not extend the URN syntax to allow 191 characters outside the ASCII range [RFC20], which implies that any 192 such characters need to be percent-encoded as described in the URI 193 specification [RFC3986]. 195 The syntax for a URN is defined as follows using the Augmented 196 Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined 197 below (i.e., alphanum, pchar, path-absolute, query, and fragment) are 198 defined in [RFC3986]. 200 namestring = assigned-name 201 [ q-component ] 202 [ f-component ] 203 assigned-name = "urn" ":" NID ":" NSS [ p-component ] 204 NID = (alphanum) 0*30(ldh) (alphanum) 205 ldh = alphanum / "-" 206 NSS = 1*(pchar) 207 p-component = "/" path-absolute 208 q-component = "?" query 209 f-component = "#" fragment 211 Note that "/" can be used without percent-encoding inside 212 p-components and that "?" can be used without percent-encoding inside 213 q-components and f-components. 215 The following sections provide additional information about these 216 rules. 218 3.1. Namespace Identifier Syntax 220 The syntax here is slightly more restrictive than what was defined in 221 [RFC2141], since it forbids the character "-" at the end of a NID. 223 NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent). 225 Characters outside the ASCII range are not permitted in NIDs, and no 226 encoding mechanism for such characters is supported. 228 3.2. Namespace Specific String Syntax 230 Depending on the rules governing a namespace, names that are valid in 231 a namespace might contain characters that are not allowed by the 232 "pchar" production referenced above (e.g., characters outside the 233 ASCII range or characters that are reserved in URIs, such as "/", 234 "?", and "#"). While such a string might be a valid name, it is not 235 a valid URN until is has been translated into a conformant NSS. 236 Translation is done by percent-encoding each disallowed character 237 using the method defined in Section 2.1 of the generic URI 238 specification [RFC3986]. Note that the "%" character is allowed only 239 for the purpose of percent-encoding. 241 In order to make URNs as stable and persistent as possible when 242 protocols evolve and the environment around them changes, namespaces 243 SHOULD NOT allow characters outside the basic Latin repertoire 244 [RFC20] unless the nature of the particular namespace makes such 245 characters necessary. 247 If a namespace designates one or more characters conforming to the 248 "pchar" rule as having special meaning for that namespace (e.g., "@") 249 and the namespace also uses that character in a literal sense, when 250 used in a literal sense the character MUST be percent-encoded (e.g., 251 "%40"). For related considerations with regard to NID registration, 252 see below. 254 3.3. p-component, q-component, and f-component 256 The p-component, q-component, and f-component are optional components 257 that follow the assigned-name. In terms of URI syntax these 258 components are essentially equivalent to the URI "path-absolute", 259 "query", and "fragment" constructions, respectively. However, the 260 URN p-component, q-component, and f-component need not be 261 semantically equivalent to the URI path component, query component, 262 and fragment component; therefore they are called by different names 263 in this specification. 265 Unless specifically defined for a particular namespace after 266 publication of this document, use of these components is disallowed, 267 thereby maintaining strict backward compatibility with namespaces 268 defined in accordance with [RFC2141] and registered in accordance 269 with [RFC3406]. 271 This specification does not define the semantics of the p-component, 272 q-component, and f-component for URNs in general. Instead, 273 additional specifications might establish these matters for URN- 274 related services (such as URN resolution) or for individual URN 275 namespaces (e.g., to handle extended information about the resource 276 identified by a URN). For example, it is possible that the 277 q-component might be used in requests to URN resolution services, or 278 that the f-component might be used to distinguish the integral parts 279 of resources named by URNs in particular namespaces (say, the 280 chapters of a book). However, defining such usage is the 281 responsibility of specifications for URN resolution services, 282 namespace registration requests and specifications for individual 283 namespaces, and other appropriate documentation (such as policy 284 documents governing the management of a given URN namespace). 286 As general guidance that might not apply to all cases, it would be 287 inappropriate for namespaces that do not intend to support resolution 288 services to allow q-components. Namespaces that deal with digital 289 manifestations might be able to support f-components. At the time of 290 writing, no general guidance can be provided for use of p-components. 292 3.3.1. p-component 294 The only formal restriction placed upon a p-component by this 295 specification is that the syntax SHALL adhere to the "path-absolute" 296 rule from [RFC3986]. The specification for a particular namespace or 297 URN-related service MAY define further syntax restrictions within the 298 p-component. (For example, a namespace specification might define a 299 character such as "~" or "@" as a delimiter inside p-components 300 assigned within that namespace.) Note that characters outside the 301 ASCII range [RFC20] MUST be percent-encoded using the method defined 302 in Section 2.1 of the generic URI specification [RFC3986]. 304 Consider the hypothetical example of a hierarchical naming system in 305 which the identifiers take the form of a series of numbers separated 306 by the "/" character, such as "1/406/47452/2". If the naming 307 authority for such identifiers were to use URNs, it would be natural 308 to place the existing identifiers in the p-component, resulting in 309 URNs such as "urn:example/1/406/47452/2" (using the "example" URN 310 namespace [RFC6963] instead of a registered NID). 312 As described under Section 4, the p-component SHALL be taken into 313 account when determining URN equivalence. 315 3.3.2. q-component 317 The only formal restriction placed upon a q-component by this 318 specification is that the syntax SHALL adhere to the "query" rule 319 from [RFC3986] (prepended by the "?" character). The specification 320 for a particular namespace or URN-related service MAY define further 321 syntax restrictions within the q-component. (For example, a 322 namespace specification might define a character such as ";" or "=" 323 as a delimiter inside q-components assigned within that namespace.) 324 Note that characters outside the ASCII range [RFC20] MUST be percent- 325 encoded using the method defined in Section 2.1 of the generic URI 326 specification [RFC3986]. 328 Consider the hypothetical example of passing parameters to a 329 resolution service that returns metadata about a resource (say, 330 Dublin Core [RFC5013] data about a published book). This could 331 perhaps be accomplished by specifying the desired metadata field 332 (e.g., "description") in the q-component, resulting in URNs such as 333 "urn:example:0-395-36341-1?operation=search&field=description". 335 As described under Section 4, the q-component SHALL NOT be taken into 336 account when determining URN equivalence. 338 3.3.3. f-component 340 The only formal restriction placed upon an f-component by this 341 specification is that the syntax SHALL adhere to the "fragment" rule 342 from [RFC3986] (prepended by the "#" character). The specification 343 for a particular namespace or URN-related service MAY define further 344 syntax restrictions within the f-component. (For example, a 345 namespace specification might define a character such as "&" or "+" 346 as a delimiter inside f-components assigned within that namespace.) 347 Note that characters outside the ASCII range [RFC20] MUST be percent- 348 encoded using the method defined in Section 2.1 of the generic URI 349 specification [RFC3986]. 351 Consider the hypothetical example of obtaining resources that are 352 part of a larger entity (e.g., chapters of a book). Each part could 353 be specified in the f-component, resulting in URNs such as 354 "urn:example:978-952-10-7060-0#chapter1". 356 As described under Section 4, the f-component SHALL NOT be taken into 357 account when determining URN equivalence. 359 4. Equivalence of URNs 361 4.1. Procedure 363 For various purposes such as caching, often it is desirable to 364 determine if two URNs are "the same". This is done by testing for 365 equivalence (see Section 6.1 of [RFC3986]). 367 The generic URI specification [RFC3986] is very flexible about 368 equality comparisons, putting the focus on allowing false negatives 369 and avoiding false positives. If comparisons are made in a scheme- 370 independent way, i.e., as URI comparisons only, URNs that this 371 specification considers equal would be rejected. The discussion 372 below applies when the URIs involved are known to be URNs. 374 Two URNs are equivalent if the s are octet-by-octet 375 equal after applying case normalization (as specified in 376 Section 6.2.2.1 of [RFC3986]) to the following constructs: 378 1. the URI scheme "urn", by conversion to lower case 380 2. the NID, by conversion to lower case 382 3. any percent-encoded characters in the NSS (that is, all character 383 triplets that match the production found in 384 Section 2.1 of the base URI specification [RFC3986]), by 385 conversion to upper case for the digits A-F. 387 Percent-encoded characters MUST NOT be decoded, i.e., percent- 388 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 389 MUST NOT be applied. 391 If a p-component is included in a URN, it MUST be identical 392 (including case sensitivity) in the strings being compared. 394 If a q-component or f-component (or both) are included in a URN, it 395 MUST be ignored for purposes of determining equivalence. 397 URN namespace definitions may include additional rules for 398 equivalence, such as case-insensitivity of the NSS (or parts 399 thereof). Such rules MUST always have the effect of eliminating some 400 of the false negatives obtained by the procedure above and MUST NOT 401 result in treating two URNs as not equivalent if the procedure here 402 says they are equivalent. For related considerations with regard to 403 NID registration, see below. 405 4.2. Examples 407 This section shows a variety of URNs (using the "example" NID defined 408 in [RFC6963]) that highlight the equivalence rules. 410 First, because the scheme and NID are case-insensitive, the following 411 URNs are equivalent to each other: 413 o urn:example:a123,z456 415 o URN:example:a123,z456 417 o urn:EXAMPLE:a123,z456 419 Second, because the q-component and f-component are not taken into 420 account for purposes of testing equivalence, the following URNs are 421 equivalent to the first three examples above: 423 o urn:example:a123,z456?abc 425 o urn:example:a123,z456#789 427 o urn:example:a123,z456#abc 429 Third, because the p-component is taken into account for purposes of 430 equivalence, the following URNs are not equivalent to each other or 431 to the foregoing URNs: 433 o urn:example:a123,z456/foo 434 o urn:example:a123,z456/bar 436 o urn:example:a123,z456/baz 438 Fourth, because of percent-encoding, the following URNs are 439 equivalent only to each other (although %2C is the percent-encoded 440 transformation of "," from the previous examples, such sequences are 441 not decoded for purposes of testing equivalence): 443 o urn:example:a123%2Cz456 445 o URN:EXAMPLE:a123%2cz456 447 Fifth, because characters other than percent-encoded sequences in the 448 NSS are treated in a case-insensitive manner, the following URNs are 449 not equivalent to the first three URNs: 451 o urn:example:A123,z456 453 o urn:example:a123,Z456 455 Sixth, on casual visual inspection of a URN presented in a human- 456 oriented interface the following URN might appear the same as the 457 first three URNs (since U+0430 CYRILLIC SMALL LETTER A can be 458 confused with U+0061 LATIN SMALL LETTER A), but it is not equivalent: 460 o urn:example:%D0%B0123,z456 462 5. URI Conformance 464 Because a URN is, syntactically, a URI under the "urn" scheme, in 465 theory a URN can be placed in any protocol slot that allows for a URI 466 (e.g., the 'href' and 'src' attributes in HTML, the element 467 in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' 468 attribute in XML for XML namespace names [XML-NAMES]). However, this 469 does not imply that, semantically, it always makes sense in practice 470 to place a URN in a given URI protocol slot; in particular, because a 471 URN might not specify the location of a resource or even point 472 indirectly to one, it might not be appropriate to place a URN in a 473 URI protocol slot that points to a resource (e.g., the aforementioned 474 'href' and 'src' attributes). Ultimately, guidelines regarding when 475 it is appropriate to use URIs under the "urn" scheme (or any other 476 scheme) are the responsibility of specifications for individual URI 477 protocol slots (e.g., the specification for the 'xml:base' attribute 478 in XML might recommend that it is inappropriate to use URNs in that 479 protocol slot). This specification cannot possibly anticipate all of 480 the relevant cases, and it is not the place of this specification to 481 require or restrict usage for individual protocol slots. 483 Despite the fact that URNs are not hierarchical and are not 484 appropriate for use as a base URI (see Section 5.1 of [RFC3986]), the 485 relative resolution algorithm specified in Section 5.2 of [RFC3986] 486 still applies to the "urn" URI scheme; implementers need to be aware, 487 however, that running the algorithm against URNs will lead to results 488 that might be unexpected or not useful. 490 In part because of the separation of semantics from syntax 491 [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay 492 special attention to the parsing and analysis rules of RFC 3986 and, 493 in particular, must treat the URI as opaque unless the scheme and its 494 requirements are recognized, in which case they may be in a position 495 to invoke scheme-appropriate processing such as by a URN resolver. 496 The URN resolver can either be an external resolver that the URI 497 resolver knows of, or it can be functionality built into the URI 498 resolver. Note that this requirement MAY impose constraints on the 499 contexts in which URNs are appropriately used; see the previous 500 section. 502 To minimize user confusion, a URI browser SHOULD display the complete 503 URN (including the "urn" scheme and any components) to ensure that 504 there is no confusion between URN namespace identifiers and URI 505 scheme identifiers. For example, a URI beginning with "urn:xmpp:" 506 [RFC4854] is very different from a URI beginning with "xmpp:" 507 [RFC5122]. Similarly, a potential DOI scheme [DOI-URI] is different 508 from, and possibly completely unrelated to, a possible DOI URN 509 namespace. 511 When URNs are transported and exchanged, they MUST be represented in 512 this format. Further, all URN-aware applications MUST offer the 513 option of displaying URNs in this canonical form to allow for direct 514 transcription (for example by cut and paste techniques). Such 515 applications might support display of URNs in a more human-friendly 516 form and might use a character set that includes characters that are 517 not permitted in URN syntax as defined in this specification (e.g., 518 when displaying URNs to humans, such applications might replace 519 percent-encoded strings with characters from an extended character 520 repertoire such as Unicode [UNICODE]). 522 As mentioned, the assignment of URNs is a managed process, as is the 523 assignment of namespaces themselves. Although design of the URNs to 524 be assigned within a given namespace is ceded by this specification 525 to the namespace owner, doing so in a managed way avoids the problems 526 inherent in unmanaged generation of URIs as described in the 527 recommendations regarding URI design and ownership [RFC7320]. 529 6. URN Namespaces 531 A URN namespace is a collection of identifiers that obey three 532 constraints. Such a namespace is (1) unique, (2) assigned in a 533 consistent way, and (3) assigned according to a common definition. 535 1. The "uniqueness" constraint means that an identifier within the 536 namespace is never assigned to more than one resource and never 537 reassigned to a different resource, even if the identifier itself 538 is deprecated or becomes obsolete. 540 2. The "consistent assignment" constraint means that an identifier 541 within the namespace is assigned by an organization or created in 542 accordance with a process or algorithm that is always followed. 544 3. The "common definition" constraint means that there are clear 545 definitions for the syntax of identifiers within the namespace 546 and for the process of assigning or creating them. 548 A URN namespace is identified by a particular NID in order to ensure 549 the global uniqueness of URNs and, optionally, to provide a cue 550 regarding the structure of URNs assigned within a namespace. 552 With regard to global uniqueness, using different NIDs for different 553 collections of identifiers ensures that no two URNs will be the same 554 for different resources, since each collection is required to 555 uniquely assign each identifier. However, a single resource can have 556 more than one URN assigned to it for different purposes (for example, 557 if a book were published in a monograph series, it could have both an 558 ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two 559 URNs referring to the same book). Subject to other constraints, such 560 as those imposed by the URI syntax [RFC3986], the rules of the URN 561 scheme are intended to allow preserving the normal and natural form 562 of identifiers specified elsewhere and treated as URN namespaces. 564 With regard to the structure of URNs assigned within a namespace, the 565 development of an identifier structure (and thereby a collection of 566 identifiers) depends on the requirements of the community defining 567 the identifiers, how the identifiers will be assigned and used, etc. 568 These issues are beyond the scope of URN syntax and the general rules 569 for URN namespaces, because they are specific to the community 570 defining a namespace (e.g., the bibliographic and publishing 571 communities in the case of the 'ISBN' and 'ISSN' namespaces, or the 572 developers of extensions to the Extensible Messaging and Presence 573 Protocol in the case of the 'XMPP' namespace). 575 URN namespaces inherit certain rights and responsibilities by the 576 nature of URNs, e.g.: 578 1. They uphold the general principles of a well-managed URN 579 namespace by providing persistent identification of resources and 580 unique assignment of identifier strings. 582 2. They can be registered in global registration services. 584 There are two types of URN namespace: formal and informal. These are 585 distinguished by the expected level of service, the information 586 needed to define the namespace, and the procedures for registration. 587 Because the majority of the namespaces registered so far have been 588 formal, this document concentrates on formal namespaces. 590 Note: [RFC3406] defined a third type of "experimental namespaces", 591 denoted by prefixing the namespace identifier with the string "X-". 592 Consistent with general IETF conclusions about that approach 593 [RFC6648], this specification removes the experimental category and 594 syntax. Because experimental namespaces were never registered, 595 removing the experimental category has no impact on the existing 596 registries or future registration procedures. Because they are not 597 registered, strings that refer to existing experimental namespaces 598 are not valid URNs. Truly experimental usages can, of course, employ 599 the 'example' namespace [RFC6963]. 601 6.1. Formal Namespaces 603 A formal namespace provides benefit to some subset of users on the 604 Internet. In particular, it would not make sense for a formal 605 namespace to be used only by a community or network that is not 606 connected to the Internet. For example, it would be inappropriate 607 for a NID to effectively force someone to use a proprietary network 608 or service not open to the general Internet user. The intent is 609 that, while the community of those who might actively use the names 610 assigned within that NID might be small, the potential use of 611 identifiers within that NID is open to any user on the Internet. 612 Formal NIDs might be appropriate even when some aspects are not fully 613 open. For example, a namespace might make use of a fee-based, 614 privately managed, or proprietary registry for assignment of URNs in 615 the namespace. However, it might still benefit some Internet users 616 if the associated services have openly-published access protocols. 618 An organization that will assign URNs within a formal namespace 619 SHOULD meet the following criteria: 621 1. Organizational stability and the ability to maintain the URN 622 namespace for a long time; absent such evidence, it ought to be 623 clear how the namespace can remain viable if the organization can 624 no longer maintain the namespace. 626 2. Competency in name assignment. This will improve the likelihood 627 of persistence (e.g. to minimize the likelihood of conflicts). 629 3. Commitment to not reassigning existing names and to allowing old 630 names to continue to be valid (e.g., if the assignee of a name is 631 no longer a member or customer of the assigning organization, if 632 various information about the assignee or named entity happens to 633 change, or even if the assignee or the named entity itself is no 634 longer in existence; in all these cases, the name is still 635 valid). 637 A formal namespace establishes a particular NID, subject to the 638 following constraints (above and beyond the syntax rules already 639 specified): 641 1. It MUST NOT be an already-registered NID. 643 2. It MUST NOT start with "urn-" (which is reserved for informal 644 namespaces). 646 3. It MUST be more than two characters long. 648 4. It MUST NOT start with "aa-", where "aa" is any combination of 649 two ASCII letters and the hyphen is followed by something other 650 than another hyphen. 652 5. It MUST NOT start with the string "xn--" or any other string 653 consisting of two letters followed by two hyphens. Those strings 654 are reserved for potential representation of DNS A-labels and 655 similar strings in the future [RFC5890]. 657 All two-letter strings, and all two-letter strings followed by "-" 658 and any sequence of valid NID characters, are reserved for potential 659 use as NIDs based on ISO alpha-2 country codes [ISO3166-1] for 660 eventual national registrations of URN namespaces. The definition 661 and scoping of rules for allocation of responsibility for such 662 country-code-based namespaces is beyond the scope of this document. 664 Applicants and reviewers considering new NIDs should also be aware 665 that they may be considered as names with semantic implications and 666 hence a source of conflict. Particular attention should be paid to 667 strings that might be construed as names of, or registered under the 668 authority of, countries (including ISO 3166-1 alpha-3 codes) and to 669 strings that might imply association with well-known trademarks. In 670 line with traditional policies, disputes about "ownership" of 671 particular strings are disagreements among the parties involved; 672 neither IANA nor the IETF will become involved in such disputes 673 except in response to orders from a court of competent jurisdiction. 675 6.2. Informal Namespaces 677 Informal namespaces are full-fledged URN namespaces, with all the 678 associated rights and responsibilities. Informal namespaces differ 679 from formal namespaces in the process for assigning a NID: for an 680 informal namespace, the registrant does not designate the NID; 681 instead, IANA assigns a NID consisting of the string 'urn-' followed 682 by one or more digits (e.g., "urn-7") where the digits consist of the 683 next available number in the sequence of positive integers assigned 684 to informal namespaces. Thus the syntax of an informal namespace is: 686 InformalNamespaceName = "urn-" Number 687 Number = DigitNonZero 0*Digit 688 DigitNonZero = "1"/ "2" / "3" / "4"/ "5" 689 / "6" / "7" / "8" / "9" 690 Digit = "0" / DigitNonZero 692 The only restrictions on are that it (1) consist strictly of 693 ASCII digits, that it (2) not have leading zeros, and that it (3) not 694 cause the NID to exceed the length limitations defined for the URN 695 syntax. 697 7. Defining and Registering a URN Namespace 699 7.1. Overview 701 Because the space of URN namespaces is itself managed, the definition 702 of a namespace SHOULD pay particular attention to: 704 1. The purpose of the namespace. 706 2. The syntax of URNs assigned within the namespace, including 707 whether p-, q-, and/or f-components are allowed. 709 3. The process for assigning URNs within the namespace. 711 4. The security implications of assigning URNs within the namespace 712 and using the assigned URNs. 714 5. Any potential interoperability issues with URNs assigned within 715 the namespace. 717 6. Optionally, the process for resolving URNs issued within the 718 namespace. 720 The section on completing the template (Section 7.3) explains these 721 matters in greater detail. 723 7.2. Registration Policy and Process 725 The basic registration policy for URN namespaces is Expert Review as 726 defined in the "IANA Considerations" document [RFC5226]. For 727 namespaces or their definitions that are intended to become standards 728 or normative components of standards, the output of the Expert Review 729 process is intended to be a report, rather than instructions to IANA 730 to take action (see below). The key steps are: 732 1. Fill out the namespace registration template (see Appendix A). 733 This can be done as part of an Internet-Draft or a specification 734 in another series, although that is not necessary. 736 2. Send the completed template to the urn-nid@ietf.org discussion 737 list for review. 739 3. If necessary to address comments received, repeat steps 1 and 2. 741 4. If the designated experts approve the request and no 742 standardization action is involved, the IANA will register the 743 requested NID. If standardization is anticipated, the designated 744 experts will prepare a report and forward it to the appropriate 745 standards approval body (the IESG in the case of the IETF) and 746 IANA will register the requested NID only after receiving 747 directions from that body and a copy of the expert review report. 749 A namespace registration can be revised by updating the registration 750 template, following the same steps outlined above for new 751 registrations. A revised registration MUST describe differences from 752 prior versions and SHOULD make special note of any relevant changes 753 in the underlying technologies or namespace management processes. 755 Experience to date with namespace registration requests has shown 756 that registrants sometimes do not initially understand some of the 757 subtleties of URN namespaces, and that defining the namespace in the 758 form of a specification enables the registrants to clearly formulate 759 their "contract" with the intended user community. Therefore, 760 although the registration policy for formal namespaces is Expert 761 Review and a specification is not strictly required, it is 762 RECOMMENDED for registrants to provide a stable specification 763 documenting the namespace definition and expanding upon the issues 764 described below. 766 Because naming can be difficult and contentious, namespace 767 registrants and the designated experts are strongly encouraged to 768 work together in a spirit of good faith and mutual understanding to 769 achieve rough consensus on handling registration requests. They are 770 also encouraged to bring additional expertise into the discussion if 771 that would be helpful in adding perspective or otherwise resolving 772 issues. 774 Especially when iterations in the registration process are prolonged, 775 designated experts are expected to take reasonable precautions to 776 avoid race conditions on proposed NID names and, if such situations 777 arise, to encourage applicants to work any conflicts out among 778 themselves. 780 7.3. Completing the Template 782 A template for defining and registering a URN namespace is provided 783 in Appendix A. This section describes considerations for completing 784 the template. 786 7.3.1. Purpose 788 The "Purpose" section of the template describes matters such as: 790 1. The kinds of resources identified by URNs assigned within the 791 namespace. 793 2. Why it is preferable to use URNs rather than some other 794 technology (e.g., separate URI schemes or URIs in existing 795 schemes) and why no existing URN namespace is a good fit. 797 3. The kinds of software applications that can use or resolve the 798 assigned URNs (e.g., by differentiating among disparate 799 namespaces, identifying resources in a persistent fashion, or 800 meaningfully resolving and accessing services associated with the 801 namespace). 803 4. The scope of the namespace (public vs. private, global vs. local 804 to a particular organization, nation, or industry). For example, 805 a namespace claiming to deal in "national identification numbers" 806 might be expected to have a global scope and address all identity 807 number structures, whereas a URN scheme for a particular national 808 identification number system would need to handle only the 809 structure for that nation's identity numbers. 811 5. How the intended community (and the Internet community at large) 812 will benefit from using or resolving the assigned URNs. 814 6. If the namespace or its definition are expected to become an 815 integral and/or normative element of a standard being developed 816 in the IETF or some other recognized standards body, that 817 intention should be noted in this section. 819 7.3.2. Syntax 821 The "Syntax" section of the template contains: 823 1. A description of the structure of URNs within the namespace, in 824 conformance with the fundamental URN syntax. The structure might 825 be described in terms of a formal definition (e.g., using 826 Augmented BNF for Syntax Specifications (ABNF) as specified in 827 [RFC5234]), an algorithm for generating conformant URNs, or a 828 regular expression for parsing the identifier into components; 829 alternatively, the structure might be opaque. 831 2. Any special character encoding rules for assigned URNs (e.g., 832 which character ought to always be used for single-quotes). 834 3. If p-components, q-components, and/or f-components are allowed 835 for the namespace, a discussion of how they are used. 837 4. Rules for determining equivalence between two identifiers in the 838 namespace. Such rules ought to always have the effect of 839 eliminating false negatives that might otherwise result from 840 comparison. If it is appropriate and helpful, reference can be 841 made to specific equivalence rules defined in the URI 842 specification [RFC3986]. Examples of equivalence rules include 843 equivalence between uppercase and lowercase characters in the 844 Namespace Specific String, between hyphenated and non-hyphenated 845 groupings in the identifier string, or between single-quotes and 846 double-quotes. (Note that these are not normative statements for 847 any kind of best practice related to handling of equivalences 848 between characters in general; they are statements limited to one 849 particular namespace only.) 851 5. Any special considerations necessary for conforming with the URN 852 syntax. This is particularly applicable in the case of existing 853 naming systems that are used in the context of URNs. For 854 example, if a namespace is used in contexts other than URNs, it 855 might make use of characters that are reserved in the URN syntax. 856 This section ought to note any such characters, and outline 857 necessary mappings to conform to URN syntax. Normally, this will 858 be handled by percent-encoding the character as specified in the 859 URI specification [RFC3986]. 861 7.3.3. Assignment 863 The "Assignment" section of the template describes matters such as: 865 1. Mechanisms or authorities for assigning URNs to resources. It 866 ought to make clear whether assignment is completely open (e.g., 867 following a particular procedure such as first-come, first-served 868 (FCFS)), completely closed (e.g., for a private organization), or 869 limited in various ways (e.g., delegated to authorities 870 recognized by a particular organization); if limited, it ought to 871 explain how to become an assigner of identifiers or how to 872 request assignment of identifiers from existing assignment 873 authorities. 875 2. Methods for ensuring that URNs within the namespace are unique. 876 For example, identifiers might be assigned sequentially or in 877 accordance with some well-defined process by a single authority, 878 assignment might be partitioned among delegated authorities that 879 are individually responsible for respecting uniqueness rules, or 880 URNs might be created independently following an algorithm that 881 itself guarantees uniqueness. 883 7.3.4. Security and Privacy 885 The "Security and Privacy" section of the template describes any 886 potential issues related to security and privacy with regard to 887 assignment, use, and resolution of identifiers within the namespace. 888 Examples of such issues include: 890 o The consequences of producing false negatives and false positives 891 during comparison for equivalence (see "Issues in Identifier 892 Comparison for Security Purposes" [RFC6943]) 894 o Leakage of private information when identifiers are communicated 895 on the public Internet 897 o The potential for directory harvesting 899 o Various issues discussed in the guidelines for security 900 considerations in RFCs [RFC3552] and the privacy considerations 901 for Internet protocols [RFC6973]. 903 7.3.5. Interoperability 905 The "Interoperability" section MUST specify any potential issues 906 related to interoperability. Examples include possible confusion 907 with other URN namespaces or naming systems because of syntax (e.g., 908 percent-encoding of certain characters) or scope (e.g., overlapping 909 areas of interest). 911 7.3.6. Resolution 913 The "Resolution" section MUST specify whether resolution mechanisms 914 are supported or anticipated for URNs assigned within the namespace, 915 and if so SHOULD specify or reference the rules governing those 916 mechanisms. 918 In particular, if resolution is anticipated and resolver registration 919 of some kind is required, for example via a Resolution Discovery 920 System [RFC2276], this section SHOULD list the requirements for 921 becoming a recognized resolver of URNs in the relevant namespace. 923 8. IANA Considerations 925 8.1. URI Scheme 927 This section updates the registration of the 'urn' URI scheme in the 928 Permanent URI Registry [URI-Registry] . 930 [Note to RFC Editor: please replace "[ this document ]" with "RFC" 931 and the number assigned to this document upon publication.] 933 URI Scheme Name: urn 935 Status: permanent 937 URI Scheme Syntax: See Section 3 of [ this document ]. 939 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 940 Names, which are persistent, location-independent resource 941 identifiers. 943 Encoding Considerations: See Section 3.2 of [ this document ]. 945 Applications/Protocols That Use This URI Scheme Name: Uniform 946 Resource Names are used in a wide variety of applications, 947 including bibliographic reference systems and as names for 948 Extensible Markup Language (XML) namespaces. 950 Interoperability Considerations: See Section 5 of [ this document ]. 952 Security Considerations: See Section 7.3.4 and Section 9 of [ this 953 document ]. 955 Contact: URNBIS WG [mailto:urn@ietf.org] 957 Author/Change Controller: This scheme is registered under the IETF 958 tree. As such, the IETF maintains change control. 960 References None. 962 8.2. Registration of URN Namespaces 964 This document outlines the processes for registering URN namespaces, 965 and has implications for the IANA in terms of registries to be 966 maintained. In all cases, the IANA ought to assign the appropriate 967 NID (formal or informal) once the procedures outlined in this 968 document have been completed. 970 9. Security and Privacy Considerations 972 The definition of a URN namespace needs to account for potential 973 security and privacy issues related to assignment, use, and 974 resolution of identifiers within the namespace (e.g., some namespace 975 resolvers might assign special meaning to certain characters in the 976 Namespace Specific String); see Section 7.3.4 for further discussion. 978 In most cases, URN namespaces provide a way to declare public 979 information. Nominally, these declarations will have a relatively 980 low security profile, however there is always the danger of 981 "spoofing" and providing misinformation. Information in these 982 declarations ought to be taken as advisory. 984 10. References 986 10.1. Normative References 988 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 989 October 1969. 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, March 1997. 994 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 995 Resource Identifier (URI): Generic Syntax", STD 66, RFC 996 3986, January 2005. 998 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 999 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1000 May 2008. 1002 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1003 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1005 [URI-Registry] 1006 IANA, "Permanent URI Schemes", 1007 . 1010 [ISO3166-1] 1011 ISO, "Codes for the representation of names of countries 1012 and their subdivisions -- Part 1: Country codes", ISO 1013 3166-1:2013, 2013. 1015 10.2. Informative References 1017 [I-D.ietf-urnbis-semantics-clarif] 1018 Klensin, J., "URN Semantics Clarification", draft-ietf- 1019 urnbis-semantics-clarif-01 (work in progress), February 1020 2015. 1022 [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The 1023 "doi" URI Scheme for the Digital Object Identifier (DOI)", 1024 June 2003, 1025 . 1027 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1028 Uniform Resource Names", RFC 1737, December 1994. 1030 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1032 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1033 Name Resolution", RFC 2276, January 1998. 1035 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1036 Standard Number) as URN (Uniform Resource Names) within an 1037 ISSN-URN Namespace", RFC 3044, January 2001. 1039 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1040 Book Numbers as Uniform Resource Names", RFC 3187, October 1041 2001. 1043 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1044 "Uniform Resource Names (URN) Namespace Definition 1045 Mechanisms", BCP 66, RFC 3406, October 2002. 1047 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1048 Text on Security Considerations", BCP 72, RFC 3552, July 1049 2003. 1051 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1052 for Extensions to the Extensible Messaging and Presence 1053 Protocol (XMPP)", RFC 4854, April 2007. 1055 [RFC5013] Kunze, J. and T. Baker, "The Dublin Core Metadata Element 1056 Set", RFC 5013, August 2007. 1058 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1059 (IRIs) and Uniform Resource Identifiers (URIs) for the 1060 Extensible Messaging and Presence Protocol (XMPP)", RFC 1061 5122, February 2008. 1063 [RFC5890] Klensin, J., "Internationalized Domain Names for 1064 Applications (IDNA): Definitions and Document Framework", 1065 RFC 5890, August 2010. 1067 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1068 "Deprecating the "X-" Prefix and Similar Constructs in 1069 Application Protocols", BCP 178, RFC 6648, June 2012. 1071 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 1072 Purposes", RFC 6943, May 2013. 1074 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 1075 for Examples", BCP 183, RFC 6963, May 2013. 1077 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1078 Morris, J., Hansen, M., and R. Smith, "Privacy 1079 Considerations for Internet Protocols", RFC 6973, July 1080 2013. 1082 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1083 7320, July 2014. 1085 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-, 1086 . 1088 [XML-BASE] 1089 Marsh, J. and R. Tobin, "XML Base (Second Edition)", World 1090 Wide Web Consortium Recommendation REC-xmlbase-20090128, 1091 January 2009, 1092 . 1094 [XML-NAMES] 1095 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 1096 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 1097 Web Consortium Recommendation REC-xml-names-20091208, 1098 December 2009, 1099 . 1101 Appendix A. Registration Template 1103 A.1. Namespace ID 1105 Requested of IANA (formal) or assigned by IANA (informal). 1107 A.2. Version 1109 The version of the registration, starting with 1 and incrementing by 1110 1 with each new version. 1112 A.3. Date 1114 The date when the registration is requested of IANA, using the format 1115 YYYY-MM-DD. 1117 A.4. Registrant 1119 The person or organization that has registered the NID, including the 1120 following information: 1122 o The name and address of the registering organization. 1124 o The name and contact information (email, phone number, and/or 1125 postal address) of the designated contact person. 1127 A.5. Purpose 1129 Described under Section 7.3.1 of this document. 1131 A.6. Syntax 1133 Described under Section 7.3.2 of this document. Unless the 1134 registration explicitly says otherwise, use of p-, q-, and/or 1135 f-components is not allowed for this namespace. 1137 A.7. Assignment 1139 Described under Section 7.3.3 of this document. 1141 A.8. Security and Privacy 1143 Described under Section 7.3.4 of this document. 1145 A.9. Interoperability 1147 Described under Section 7.3.5 of this document. 1149 A.10. Resolution 1151 Described under Section 7.3.6 of this document. 1153 A.11. Documentation 1155 A pointer to an RFC, a specification published by another standards 1156 development organization, or another stable document that provides 1157 further information about the namespace. 1159 A.12. Revision Information 1161 (Applicable only when earlier registrations have been revised.) 1163 Description of changes from prior version(s). 1165 Appendix B. Changes from RFC 2141 1167 This document makes the following substantive changes from [RFC2141]: 1169 o Allows p-components, q-components, and f-components. 1171 o Disallows "-" at the end of a NID. 1173 o Allows the "~" and "&" characters in an NSS. 1175 o Formally registers 'urn' as a URI scheme. 1177 Appendix C. Changes from RFC 3406 1179 This document makes the following substantive changes from [RFC3406]: 1181 1. Relaxes the registration policy for formal namespaces from "IETF 1182 Review" to "Expert Review" as discussed in Section 7.2. 1184 2. Removes the category of experimental namespaces, consistent with 1185 [RFC6648]. 1187 3. Simplifies the registration template. 1189 In addition, some of the text has been updated to be consistent with 1190 the definition of Uniform Resource Identifiers (URIs) [RFC3986] and 1191 the processes for registering information with the IANA [RFC5226], as 1192 well as more modern guidance with regard to security [RFC3552] and 1193 privacy [RFC6973] issues and identifier comparison [RFC6943]. 1195 Appendix D. Contributors 1197 RFC 2141, which provided the basis for the syntax portion of this 1198 document, was authored by Ryan Moats. 1200 RFC 3406, which provided the basis for the namespace portion of this 1201 document, was authored by Leslie Daigle, Dirk-Willem van Gulik, 1202 Renato Iannella, and Patrik Faltstrom. 1204 Their work is gratefully acknowledged. 1206 Appendix E. Acknowledgements 1208 Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha 1209 Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean 1210 Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian 1211 Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other 1212 participants in the URNBIS WG for their input. Alfred Hoenes in 1213 particular edited an earlier version of this document and served as 1214 co-chair of the URNBIS WG. 1216 Juha Hakala deserves special recognition for his dedication to 1217 successfully completing this work, as do Andrew Newton and Melinda 1218 Shore in their roles as working group co-chairs and Barry Leiba in 1219 his role as area director. 1221 Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn 1223 [[RFC Editor: please remove this appendix before publication.]] 1225 F.1. Changes from -08 to -09 1227 o Altered the text in Section 5 to reflect list discussions about 1228 the earlier phrasing. Also added DOI example and citation to that 1229 section. 1231 o Clarified the naming rules for formal namespaces and their 1232 relationship to ISO 3166, IDNA, etc., reserved strings. 1234 o Added an explicit statement about use of URNs in various protocols 1235 and contexts to Section 5. 1237 o Clarified that experimental namespace NIDs, which were explicitly 1238 not registered, are not valid URNs (in Section 6. 1240 o Transformed the partial production in Section 6.2 into valid ABNF. 1242 o Added more text about p-/q-/f-components and recommendations about 1243 use. 1245 o Added clarifying note about "?" within q-components and 1246 f-components. 1248 o Added explicit requirement that revisions of existing 1249 registrations document the changes and added a slot for that 1250 description to the template. 1252 o Many small editorial changes and adjustments including adding 1253 additional references and cross-references for clarification. 1255 o Inserted a placeholder for additional examples. 1257 F.2. Changes from -09 to -10 1259 o Several clarifying editorial changes, most suggested by Ted Hardie 1260 and Henry S. Thompson (some of them off-list). 1262 o Added a large number of placeholders that identify issues that 1263 require WG consideration and resolution (or WG delegation to the 1264 editors). 1266 F.3. Changes from -10 to -11 1268 o Removed most of the placeholders added in -10. Supplied new text 1269 as required or suggested by on-list discussion of those issues. 1271 o Replaced the conformance examples Section 4.2 with a more complete 1272 collection and discussion. 1274 o Revised and consolidated the registration procedure, and added 1275 provisions for NIDs that are the subject of standards and for 1276 avoiding race conditions about NID strings. 1278 o In response to independent comments from Ted Hardie and Henry S. 1279 Thompson, called attention to the possibility of conflicts between 1280 NID strings and various claims of national, corporate, and other 1281 perogatives. 1283 o Changed the production for assigned-name as suggested by Lars 1284 Svensson. 1286 o Several clarifying editorial changes including correcting a glitch 1287 in instructions to the RFC Editor. 1289 Authors' Addresses 1291 Peter Saint-Andre 1292 &yet 1294 Email: peter@andyet.com 1295 URI: https://andyet.com/ 1297 John C Klensin 1298 1770 Massachusetts Ave, Ste 322 1299 Cambridge, MA 02140 1300 USA 1302 Phone: +1 617 245 1457 1303 Email: john-ietf@jck.com