idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-03.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 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 == Line 1062 has weird spacing: '...service glob...' == Line 1063 has weird spacing: '...esource globa...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (October 16, 2012) is 4208 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 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 -- Obsolete informational reference (is this intentional?): RFC 615 (Obsoleted by RFC 645) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 1808 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2611 (Obsoleted by RFC 3406) -- Obsolete informational reference (is this intentional?): RFC 2717 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2718 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 4020 (Obsoleted by RFC 7120) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF URNbis WG A. Hoenes, Ed. 3 Internet-Draft TR-Sys 4 Obsoletes: 2141 (if approved) October 16, 2012 5 Intended status: Standards Track 6 Expires: April 19, 2013 8 Uniform Resource Name (URN) Syntax 9 draft-ietf-urnbis-rfc2141bis-urn-03 11 Abstract 13 Uniform Resource Names (URNs) are intended to serve as persistent, 14 location-independent, resource identifiers. This document serves as 15 the foundation of the 'urn' URI Scheme according to RFC 3986 and sets 16 forward the canonical syntax for URNs, which subdivides URNs into 17 "namespaces". A discussion of both existing legacy and new 18 namespaces and requirements for URN presentation and transmission are 19 presented. Finally, there is a discussion of URN equivalence and how 20 to determine it. This document supersedes RFC 2141. 22 The requirements and procedures for URN Namespace registration 23 documents are set forth in a companion document, RFC 3406bis (BCP 24 66). 26 Discussion 28 Comments are welcome on the urn@ietf.org mailing list (or sent to the 29 document editor). The home page of the URNbis WG is located at 30 . 31 [[ RFC-Editor: this clause to be deleted before RFC publication ]] 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 19, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Historical Perspective and Motivation . . . . . . . . . . 4 81 1.2. Objective of this Memo . . . . . . . . . . . . . . . . . . 6 82 1.3. Background on Properties of URNs . . . . . . . . . . . . . 6 83 1.4. Requirement Language . . . . . . . . . . . . . . . . . . . 8 84 2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 2.1. Namespace Identifier (NID) Syntax . . . . . . . . . . . . 10 86 2.2. Namespace Specific String (NSS) Syntax . . . . . . . . . . 10 87 2.3. Query Part in URI References to URNs . . . . . . . . . . . 11 88 2.3.1. Query Instruction for URN Service Selection . . . . . 13 89 2.3.2. Query Instruction for Component Resource Indication . 13 90 2.4. Fragment Part in URI References to URNs . . . . . . . . . 14 91 2.5. Special and Reserved Characters . . . . . . . . . . . . . 14 92 2.5.1. Delimiter Characters . . . . . . . . . . . . . . . . . 14 93 2.5.2. The Percent Character, Percent-Encoding . . . . . . . 15 94 2.5.3. Other Excluded Characters . . . . . . . . . . . . . . 16 95 3. Support of Existing (Legacy) and New Naming Systems . . . . . 17 96 4. URN Presentation and Transport . . . . . . . . . . . . . . . . 17 97 5. Lexical Equivalence of URNs . . . . . . . . . . . . . . . . . 17 98 5.1. Examples of Lexical Equivalence . . . . . . . . . . . . . 18 99 6. Functional Equivalence of URNs . . . . . . . . . . . . . . . . 19 100 7. The 'urn' URI Scheme . . . . . . . . . . . . . . . . . . . . . 19 101 7.1. Registration Template for URI Scheme 'urn' . . . . . . . . 19 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 9.1. Registration of URI Scheme 'urn', URN Registry Update . . 22 105 9.2. URN Query Parameters Registry . . . . . . . . . . . . . . 22 106 9.2.1. URN Query Keywords Sub-Registry . . . . . . . . . . . 22 107 9.2.2. URN Resolution Service Designators Sub-Registry . . . 23 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 111 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 112 Appendix A. Handling of URNs by URL Resolvers/Browsers . . . . . 28 113 Appendix B. Collected ABNF (Informative) . . . . . . . . . . . . 28 114 Appendix C. Breakdown of NSS Syntax Evolution since RFC 2141 115 (Informative) . . . . . . . . . . . . . . . . . . . . 29 116 Appendix D. Changes since RFC 2141 (Informative) . . . . . . . . 31 117 D.1. Essential Changes from RFC 2141 . . . . . . . . . . . . . 31 118 D.2. Changes from RFC 2141 to Individual Draft -00 . . . . . . 32 119 D.3. Changes from Individual Draft -00 to -02 . . . . . . . . . 33 120 D.4. Changes from Individual Draft -02 to WG Draft -00 . . . . 33 121 D.5. Changes from WG Draft -00 to WG Draft -01 . . . . . . . . 33 122 D.6. Changes from WG Draft -01 to WG Draft -02 . . . . . . . . 34 123 D.7. Changes from WG Draft -02 to WG Draft -03 . . . . . . . . 34 125 1. Introduction 127 Uniform Resource Names (URNs) are intended to serve as persistent, 128 location-independent, resource identifiers and are designed to make 129 it easy to map other namespaces (that share the properties of URNs) 130 into URI-space. Therefore, the URN syntax provides a means to encode 131 character data in a form that can be sent in existing protocols, 132 transcribed on most keyboards, etc. 134 To this end, URNs are designed as an intrinsic part of the more 135 general framework of Uniform Resource Identifiers (URIs); 'urn' is a 136 particular URI Scheme (according to STD 66, RFC 3986 [RFC3986] and 137 BCP 35, RFC 4395 [RFC4395]) that is dedicated to forming a 138 hierarchical framework for persistent identifiers. (Other, legacy 139 interpretations of the term URN are not considered in this memo.) 141 The first level of hierarchy is given by the classification of URIs 142 into "URI Schemes", and for URNs, the second level is organized into 143 "URN Namespaces". Henceforth both terms are used in this 144 capitalization to distinguish them from the more general common 145 meaning of "scheme" and "namespace". 147 It is an explicit design goal that pre-existing systems of persistent 148 identifiers are mapped into the URN framework. Ordinarily, each such 149 traditional identifier system (namespace) -- standard or otherwise -- 150 will occupy its own URN Namespace. However, shared URN Namespaces 151 are possible (and in fact, already exist), but the identifier-driven 152 mechanisms needed to distinguish the originating namespaces make 153 registration and maintenance of such URN Namespaces more complicated. 155 URN (as a URI Scheme) as such does not have a specific scope. The 156 applicability of the URN system, that is, the totality of the 157 resources that URNs can be assigned to, is the union of all 158 identifier systems that have an associated registered URN Namespace. 159 Ideally every new namespace will thus extend the URN applicability. 161 1.1. Historical Perspective and Motivation 163 Since this RFC will be of particular interest for groups and 164 individuals that are interested in persistent identifiers in general, 165 but often not in steady contact with the IETF and the RFC series, 166 this section gives a brief outline of the evolution of the matter 167 over time. 169 Attempts to define generally applicable identifiers for network 170 resources go back to the mid-1970s. Among the applicable RFCs is RFC 171 615 [RFC0615], which subsequently has been obsoleted by RFC 645 172 [RFC0645]. 174 The seminal document in the RFC series regarding URIs (Uniform 175 Resource Identifiers) for use with the World Wide Web (WWW) was RFC 176 1630 [RFC1630], published in 1994. In the same year, the general 177 concept or Uniform Resource Names has been laid down in RFC 1737 178 [RFC1737] and that of Uniform Resource Locators (URLs) in RFC 1736 179 [RFC1736]. 181 The original formal specification of URN Syntax, RFC 2141 [RFC2141] 182 was adopted in 1997. That document was based on the original 183 specification of URLs in RFC 1738 [RFC1738] and RFC 1808 [RFC1808], 184 which later on, in 1998, was generalized and consolidated in the 185 Generic URI specification, RFC 2396 [RFC2396]. Most parts of these 186 URI/URL documents were superseded in 2005 by STD 66, RFC 3986 187 [RFC3986]. Notably, RFC 2141 makes (essentially normative) reference 188 to a draft version of RFC 2396. 190 Over time, the terms "URI", "URL", and "URN" have been refined and 191 slightly shifted according to emerging insight and use. This has 192 been clarified in a joint effort of the IETF and the World Wide Web 193 Council, published 2002 for the IETF in RFC 3305 [RFC3305]. 195 The wealth of URI Schemes and URN Namespaces needs to be organized in 196 a persistent way, in order to guide application developers and users 197 to the standardized top level branches and the related 198 specifications. These registries are maintained by the Internet 199 Assigned Numbers Authority (IANA) [IANA] at [IANA-URI] and 200 [IANA-URN], respectively. Registration procedures for URI Schemes 201 originally had been laid down in RFC 2717 [RFC2717] and guidelines 202 for the related specification documents were given in RFC 2718 203 [RFC2718]. These documents have been obsoleted and consolidated into 204 BCP 35, RFC 4395 [RFC4395], which is based on, and aligned with, 205 RFC 3986. 207 Note that RFC 2141 predates RFC 2717 and, although the 'urn' URI 208 scheme traditionally was listed in [IANA-URI] with a pointer to 209 RFC 2141, this registration has never been performed formally. 211 Similarly, the URN Namespace definition and registration mechanisms 212 originally have been specified in RFC 2611 [RFC2611], which has been 213 obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents 214 prescribing IANA procedures have been revised as well over the years, 215 and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the 216 normative document. Neither RFC 4395 nor RFC 3406 conform to 217 RFC 5226. 219 Early documents specifying URI and URN syntax, including RFC 2141, 220 made use of an ad-hoc variant of the original Backus-Naur Form (BNF) 221 that never has been formally specified. 223 Over the years, the IETF has shifted to the use of a predominant 224 formal language used to define the syntax of textual protocol 225 elements, dubbed "Augmented Backus-Naur Form" (ABNF). The 226 specification of ABNF also has evolved, and now STD 68, RFC 5234 227 [RFC5234] is the normative document for it (that also will be used in 228 this RFC). 230 1.2. Objective of this Memo 232 As pointed out above, RFC 2141 does not seamlessly match current 233 Internet Standards. Therefore, the primary objective of this 234 document is the alignment with the URI standard [RFC3986] and URI 235 Scheme guidelines [RFC4395], the ABNF standard [RFC5234] and the 236 current IANA Guidelines [RFC5226] in general. 238 Further, experience from emerging international efforts to establish 239 a general, distributed, stable URN resolution service have been taken 240 into account during the draft stage of this document. 242 For advancing the URN specification on the Internet Standards-Track, 243 it needs to be based on documents of comparable maturity. Therefore, 244 to further advancements of the formal maturity level of this RFC, it 245 deliberately makes normative references only to documents at Full 246 Standard or Best Current Practice level. 248 Thus, this replacement document for RFC 2141 should make it possible 249 to advance the URN framework on the Internet Standard maturity 250 ladder. All other related documents depend on it; therefore this is 251 the first step to undertake. 253 Out of scope for this document is a revision of the URN Namespace 254 Definition Mechanisms document, BCP 66. This is being undertaken in 255 a companion document, RFC 3406bis 256 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 258 1.3. Background on Properties of URNs 260 This section aims at quoting requirements as identified in the past; 261 it does not attempt to revise or redefine these requirements, but it 262 gives some hints where more than a decade of experience with URNs has 263 shed a different light on past views. The citations below are given 264 here to make this document self-contained and avoid normative down- 265 references to old work. 267 RFC 1737 [RFC1737] defined the purpose of URNs as follows: 269 o The purpose or function of a URN is to provide a globally unique, 270 persistent identifier used for recognition, for access to 271 characteristics of the resource, or for access to the resource 272 itself. 274 This means that URNs are intended to uniquely and persistently bind a 275 name to a resource and (some of) its properties (metadata). 277 Section 2 of RFC 1737 [RFC1737] listed the functional requirements 278 for URNs (quote slightly edited to reflect the time passed since that 279 RFC was written and the actual definition of the URN scheme that has 280 happened): 282 o Global scope: A URN is a name with global scope which does not 283 imply a location. It has the same meaning everywhere. 285 o Global uniqueness: The same URN will never be assigned to two 286 different resources. 288 o Persistence: It is intended that the lifetime of a URN be 289 permanent. That is, the URN will be globally unique forever, and 290 may well be used as a reference to a resource well beyond the 291 lifetime of the resource it identifies or of any naming authority 292 involved in the assignment of its name. 294 o Scalability: URNs can be assigned to any resource that might 295 conceivably be available on the network, for hundreds of years. 297 o Legacy support: The URN scheme permits the support of existing 298 legacy naming systems, insofar as they satisfy the other 299 requirements described here. [...] 301 o Extensibility: The URN scheme permits future extensions. 303 o Independence: It is solely the responsibility of a name issuing 304 authority to determine the conditions under which it will issue a 305 name. 307 o Resolution: URNs will not impede resolution. [...] 309 The URN syntax described below also accommodates the fundamental 310 "Requirements for URN Encoding" in Section 3 of RFC 1737 [RFC1737], 311 as far as experience gained has not lead to relax unrealistical 312 detail requirements: 314 o Single encoding: The encoding for presentation for people in clear 315 text, electronic mail and the like is the same as the encoding in 316 other transmissions. 318 o Simple comparison: A comparison algorithm for URNs is simple, 319 local, and deterministic. [...] 321 o Human transcribability: For URNs to be easily transcribable by 322 humans without error, they need to be short, use a minimum of 323 special characters, and be case insensitive. [...] 325 Note: 326 In particular practice gained with active URN Namespaces has 327 shown that this former goal is rather unrealistic, since 328 usually preference is given to 1:1 embedding into URNs of 329 identifier strings drawn from existing namespaces, which might 330 not have this property. However, we hold that, at least, the 331 rough kind of resource identified by a URN should be easily 332 recognizable for humans. 334 o Transport friendliness: A URN can be transported unmodified in the 335 common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., 336 as well as printed paper. 338 o Machine consumption: A URN can be parsed by a computer. 340 o Text recognition: The encoding of a URN needs to enhance the 341 ability to find and parse URNs in free text. 343 1.4. Requirement Language 345 When spelled in all-capitals as in this paragraph, the key words 346 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 347 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 348 are to be interpreted as described in BCP 14 [RFC2119]. 350 2. URN Syntax 352 This document defines the URI Scheme 'urn'. Hence, URNs are specific 353 URIs as specified in STD 66 [RFC3986]. The formal syntax definitions 354 below are given in ABNF according to STD 68 [RFC5234] and make use of 355 some "Core Rules" specified in Appendix B of that Standard and 356 several generic rules defined in Appendix A of RFC 3986. 358 The syntax definitions below do, and syntax definitions in dependent 359 documents, MUST conform to the URI syntax specified in RFC 3986, in 360 the sense that additional syntax rules are only allowed to further 361 constrain the general rules from RFC 3986. In other words: a general 362 URI parser based on RFC 3986 MUST be able to parse any legal URN, 363 URN-specific semantics can be obtained from URN-specific parsing of 364 its outcome. 366 URNs conform to the variant of the general URI syntax 367 specified in Section 3 of [RFC3986], reproduced here informally: 369 URI = scheme ":" path-rootless [ "?" query ] [ "#" fragment ] 371 path-rootless = segment-nz *( "/" segment ) 373 segment-nz = 1*pchar 374 segment = *pchar 375 query = *( pchar / "/" / "?" ) 376 fragment = *( pchar / "/" / "?" ) 378 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 380 In the case of URNs, we have: 382 scheme = "urn" 384 and for , only a single segment is used, but the 385 following additional syntax rule is superimposed on 386 to establish a level of hierarchy called "Namespace": 388 urn-path = NID ":" NSS 390 Here "urn" is the URI scheme name, is the Namespace Identifier, 391 and is the Namespace Specific String. The colons are REQUIRED 392 separator characters. 394 Note that it is common practise in several existing URN Namespaces 395 (and fully supported by this syntax) to use additional colon(s) as 396 separator character(s) in order to introduce further level(s) of 397 hierarchy into the NSS syntax, where needed. (See also 398 Section 2.5.1 below.) 400 Per RFC 3986, the URN Scheme name (here "urn") is case-insensitive. 402 The Namespace ID (also a case-insensitive string) determines the 403 syntactic structure and the semantic interpretation of the Namespace 404 Specific String. Details on NID syntax can be found below in 405 Section 2.1, and the NSS syntax is elaborated upon in Section 2.2. 407 Each particular URN Namespace is based on a specific document that 408 must normatively describe (among other things) the details of the 409 values allowed in conjunction with the respective . The 410 syntax and semantics of these values are often carried over 411 from an existing persistent identifier system (namespace); for 412 instance, in the 'ISBN' URN Namespace, each NSS must be a valid ISBN. 413 Some URN Namespaces may have strict rules for well formed NSSs, while 414 some others may be far more relaxed. There may also be significant 415 differences regarding the identifier assignment process. The overall 416 specification requirements and registration procedures for URN 417 Namespaces are the subject of a dedicated companion document, BCP 66, 418 which has been updated for conformance to BCP 26 and alignment with 419 implementation experience RFC 3406bis 420 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 422 The syntax of and are defined in RFC 3986. 423 Question mark and hash sign remain reserved as separator characters 424 for these URI components and therefore MUST NOT appear unencoded in a 425 NSS. This rule guarantees backwards compatibility with existing URN 426 Namespaces and improves the compatibility of URN syntax with general 427 URI parsers. 429 For more specifics on the part with URNs, see Section 2.3 430 below; elaborations on the part usage with URNs follow in 431 Section 2.4 below. 433 2.1. Namespace Identifier (NID) Syntax 435 The following is the syntax for the Namespace Identifier. To (i) be 436 consistent with all potential resolution schemes and (ii) not put any 437 undue constraints on any potential resolution scheme, Namespace 438 Identifiers are ASCII strings with the syntax: 440 NID = (ALPHA / DIGIT) 0*30(ALPHA / DIGIT / "-") (ALPHA / DIGIT) 442 Note: 443 The above definition is slightly more restrictive than it was in 444 RFC 2141, to better reflect common practice for "handle"-like 445 identifiers in other IETF protocols (a.k.a. "LDH" syntax) and 446 requirements from RFC 3406bis. RFC 3406bis contains further 447 syntax restrictions on NID strings. 449 Namespace Identifiers are case-insensitive, so that for instance 450 "ISBN" and "isbn" refer to the same namespace. 452 To avoid confusion with the URI Scheme name "urn", the NID "urn" is 453 permanently reserved by this RFC and MUST NOT be used or registered. 455 2.2. Namespace Specific String (NSS) Syntax 457 As already required since RFC 1737, there is a single canonical 458 representation of the NSS portion of an URN. 460 The format of this single canonical form follows: 462 NSS = 1*pchar ; or equivalent: NSS = segment-nz 464 ( and are defined in Section 3.3 of RFC 3986.) 466 Note: 467 The informational Appendix C expands on the evolution of the NSS 468 syntax specification since RFC 2141. 470 Depending on the rules governing a namespace, valid identifiers in a 471 namespace might contain characters that are not members of the URN 472 character repertoire above (). In order to achieve 473 conformance with this NSS specification, such strings MUST be 474 translated into canonical NSS format before embedding them into a 475 URN, using them as protocol elements, or otherwise passing them on to 476 other applications. Translation is done by encoding each character 477 outside the URN character repertoire as a sequence of octets using 478 UTF-8 encoding (STD 63 [RFC3629]), and the "percent-encoding" of each 479 of those octets as "%" followed by two characters. The 480 latter two characters form the hexadecimal representation of that 481 octet. (See Section 2.5.2 below for more details.) 483 2.3. Query Part in URI References to URNs 485 The part MUST NOT be present in any *assigned* URN. A 486 part can only be added to an assigned URN and appear in a URI 487 *reference* [RFC3986] to a URN that is intended to be used with URN 488 resolution services, and, in the spirit of the general specification 489 of this part in RFC 3986, its purpose is restricted to indicate the 490 requested URN resolution service and particular service aspects of 491 the intended resolution response, e.g., the kind of metadata or 492 content sought that are bound to a given object identified by the 493 basic, assigned URN. 495 This specification only defines a generic framework format for this 496 part and basic items to be used therein; it defers more detailed 497 specifications to future standardization related to generic URN 498 services and resolution and to URN Namespace defining documents for 499 namespace-specific usages. 501 Beyond following the generic syntax rules from [RFC3986] quoted 502 above, parts of URN references MUST adhere to the following 503 restricted syntax (compatible with industry standard URL-encoding 504 practice for HTTP). 506 urn-query = directive *( "&" directive) 508 directive = keywd "=" value 509 keywd = ALPHA *( ["-"] (ALPHA / DIGIT)) 510 value = *v-pchar 512 v-pchar = unreserved / pct-encoded / v-subdels 513 v-subdels = "!" / "$" / "'" / "(" / ")" 514 / "*" / "+" / "," / ";" / "=" 515 / ":" / "@" / "/" / "?" 516 ; this is except "&" 517 ; plus the extra characters allowed in 518 ; and for , as per RFC 3986 520 The part of URN references, if present, consists of an 521 unordered sequence of "directives" of the form =, 522 separated by single instances of the ampersand character ("&"). As 523 common for parts, these directives are regarded as case- 524 sensitive. 526 The tokens are -- preferably short, mnemonic -- LDH-strings 527 of either global or namespace-centric scope. The following 528 subsections specify two basic keywords of global scope. Other 529 tokens can be specified in other documents (including URN 530 Namespace specifications) and are to be registered by IANA. See 531 Section 9.2.1 for registration details. 533 Each registered MUST NOT appear more than once in any URN. A 534 URN resolver that receives a URN reference violating this rule MUST 535 ignore all query directives therein using the offending (s) 536 (this is necessary to maintain independence of the semantics from 537 directive ordering). 539 The tokens have semantics specific to the they are 540 used with. The above syntax rule is the most liberal possible 541 specification guaranteeing unambiguity and still conforming with RFC 542 3986, but prudent specifications of tokens will keep the 543 forms admitted with them as simple as possible. 545 URN resolvers are expected to ignore query keywords they do not 546 support or understand and "gracefully" fall back to namespace- 547 specific default behavior. Similarly, unless specified otherwise in 548 the specification of a particular query keyword, URN resolvers are 549 expected to ignore directives with an unknown/unsupported for 550 a supported and provide default behavior for these cases as 551 well as if an expected directive is not supplied. New/revised URN 552 Namespace specifications need to clearly indicate which s are 553 being supported for the respective URN Namespace and the set of valid 554 s for these (by listing enumerated values and/or specifying 555 additional syntax rules) -- see RFC 3406bis for more information. 557 2.3.1. Query Instruction for URN Service Selection 559 The query keyword "s" has global scope and semantics; it serves to 560 select a specific URN resolution service. The associated is 561 the mnemonic name of the URN resolution operation intended by the URI 562 reference to a URN. Permissible values are registered with IANA by 563 the documents specifying these URN services -- see Section 9.2.2 for 564 details. Pending future revised URN service specifications, the 565 registry is initially populated with provisional entries derived from 566 RFC 2483 [RFC2483]. 568 This query keyword is expected to be supported by new URN resolution 569 systems for any URN namespaces. A URN resolver that does not support 570 this query keyword (e.g., because it is based on RFC 2141) or that 571 does not understand the handed to it MUST gracefully fall 572 back to provide the default service for the respective URN Namespace, 573 as specified in the related URN Namespace definition. New/revised 574 URN Namespace specifications need to clearly indicate which services 575 are being supported for the respective URN Namespace -- see RFC 576 3406bis for more information. 578 Example directive (URI to URL service, RFC 2483, Sec. 4.1): s=I2U 580 2.3.2. Query Instruction for Component Resource Indication 582 The query keyword "c" serves to identify a component of the resource 583 named by the basic URN in a uniform, media type independent manner; 584 it applies to structured resources only and otherwise has global 585 scope, but namespace-specific applicability, values, and semantics. 587 URN Namespace designers/maintainers MAY adopt the use of this query 588 instruction for their resolver systems and need to specify that fact 589 in the URN Namespace registration and supply the applicable rules for 590 the "c=" values to be supported by the resolvers for that URN 591 Namespace. See RFC 3406bis for more information. 593 Hypothetical example: Assuming that the ISBN Namespace adopts support 594 of the "c=" query instruction for the I2R URN service provided by 595 URN:ISBN resolvers, further assuming that for a printed book the 596 table of contents is anyway being made available online somewhere by 597 its publisher _and_ the resolver system is aware of this, and 598 provided that the resolvers support designation of the table of 599 contents via the "c" "ToC", a URI reference to the URN:ISBN 600 of such book might indicate the intent to resolve the URN to an URL 601 for that ToC by including the part "s=I2L&c=ToC". 603 2.4. Fragment Part in URI References to URNs 605 The part is not generally allowed in URNs. It is only 606 applicable to URN Namespaces that specifically opt to support its 607 usage in a manner that conforms with RFC 3986. Thus, a URN Namespace 608 registration document MAY specify the usage of with URNs 609 of that particular URN Namespace. Absent a registered namespace 610 definition based on this document and RFC 3406bis that explicitly 611 specifies its usage, URNs for that particular URN Namespace MUST NOT 612 contain a fragment identifier. 614 The part MUST NOT be present in any *assigned* URN; it MAY 615 be present in a URI *reference* to a URN that is intended to be used 616 with URN resolution services, and -- according to RFC 3986 -- it will 617 not be sent to the resolution service but be interpreted by the 618 resolution client in accordance with the specification of the 619 Internet media type returned by the URN service. 621 Note that this is a backwards-compatible and fail-safe extension 622 from RFC 2141 since, based on RFC 3986 and established 623 implementation practice, clients/browsers ignore inapplicable 624 fragment identifiers and silently fall back in such case to 625 rendering the entire resource returned. 627 The requirements for documenting the usage of fragment identifiers 628 with a particular URN Namespace are elaborated upon in RFC 3406bis 629 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg], and that document also 630 explains the different methods available to URN Namespace designers 631 for how URN assignment and resolution can deal with structured 632 resources and their components. 634 2.5. Special and Reserved Characters 636 The remaining printable characters not included in the 637 repertoire comprise the generic delimiters and the reserved 638 characters, which are restricted for special use only. These 639 characters are discussed below, giving the specifics of why each 640 character is special or reserved. 642 2.5.1. Delimiter Characters 644 RFC 3986 [RFC3986] defines the general delimiter characters used in 645 URIs: 647 gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" 649 From among the , ":" and "@" are also included in the 650 rule and hence allowed in the path components of URIs. 652 The at-character ("@") in generic URIs only has a specific meaning 653 when contained in the part, which is absent in URNs. 654 Hence, "@" is available in the part of URNs. 656 With URNs, the colon (":") is used as a delimiter character not only 657 between the scheme name ("urn") and the , but also between the 658 latter and the , and many existing URN Namespaces additionally 659 use ":" to further subdivide a single RFC 3986 path segment in the 660 in a hierarchical manner. 662 Note: 663 Using ":" as a sub-delimiter in the path in favor of "/" is 664 attractive because it avoids possible complications that could 665 arise from accidental inappropriate use of relative URI references 666 [RFC3986] for URNs. 668 The characters "/", "?", and "#" separate path components and the 669 and parts in the generic URI syntax; they are 670 restricted to this role in URNs as well, although the in URNs 671 only admits a single and hence "/" is not allowed. 672 Therefore, these characters MUST NOT appear literally in the 673 part of a URN in unencoded form. Namespaces that need these 674 characters MUST employ in their URNs the appropriate percent-encoding 675 for each such character. 677 The square brackets ("[" and "]") also play a particular role when 678 contained in the part, which is absent in URNs. However, 679 for conformance with the generic URI syntax, they are not allowed 680 literally in the component of URNs. If a specific URN 681 Namespace reflects semantics that require these characters, they MUST 682 be percent-encoded in the respective URNs. 684 2.5.2. The Percent Character, Percent-Encoding 686 The percent character ("%") is reserved in the URN syntax for 687 introducing the escape sequence for an octet that is either not a 688 printable ASCII character or reserved for special purposes, as 689 described in this section. The presence of a "%" character in a URN 690 MUST always be followed by two characters, which three 691 characters together semantically represent an abstract 692 octet. Literal use of the "%" character in an underlying namespace 693 MUST therefore be encoded as "%25" in URNs for that namespace. 695 Namespaces MAY designate one or more characters from the URN 696 character repertoire as having special meaning for that namespace 697 (e.g. as being used as a separator character between distinguishable 698 parts of the NSS). If such namespace also allows for such character 699 to occur in identifiers from that namespace in a literal sense (in a 700 part of the identifier that shall be embedded literally into the 701 NSS), the character used in a literal sense MUST be percent-encoded 702 (with "%" followed by the hexadecimal representation of that octet). 703 Further, a character MUST NOT be percent-encoded if the character is 704 not a reserved character. Therefore, the process of registering a 705 namespace identifier shall include publication of a definition of 706 which characters have a special meaning to that namespace -- cf. RFC 707 3406bis [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 709 2.5.3. Other Excluded Characters 711 The following list is included only for the sake of completeness. It 712 includes the characters discussed in Sections 2.5.1 and 2.5.2. Any 713 octets/characters on this list are explicitly NOT part of the URN 714 character repertoire, and if used in an URN, MUST be percent- 715 encoded. 717 excluded = CTL / SP ; control characters and space 718 / DQUOTE ; " 719 / "#" ; from 720 / "%" ; see above 721 / "/" ; from 722 / "<" / ">" 723 / "?" ; from 724 / "[" ; from 725 / "\" 726 / "]" ; from 727 / "^" 728 / "`" 729 / "{" / "|" / "}" 730 / %x7F ; DEL (control character) 731 / %x80-FF ; non-ASCII 733 The NUL octet (0 hex) is renowned for a long history of trouble in 734 implementations. It MUST NOT be used in URNs, in either unencoded or 735 percent-encoded form. 737 In a textual context for a URN, the NSS part ends when an octet/ 738 character from the excluded character set () is 739 encountered. The character from the excluded character set is NOT 740 part of the NSS. 742 The more general issue of discerning URNs in non-structured text is 743 not specific to URNs, but a general issue for recognizing URIs (by 744 humans or automata), and hence out of scope of this document. 746 3. Support of Existing (Legacy) and New Naming Systems 748 Any identifier to be used as a URN MUST be expressed in conformance 749 with the URI and URN syntax specifications ([RFC3986], and this 750 document). If names from (existing or newly devised) namespaces 751 contain characters other than those defined for the URN character 752 set, they MUST be translated into canonical form as discussed in 753 Section 2.2. 755 On the other hand, every namespace specific string in such URN 756 Namespace MUST be based on an identifier that conforms to the 757 requirements of the identifier system to which the URN Namespace is 758 assigned; in the simplest form, if the syntactical rules admit, the 759 NSS can be the original identifier. For instance, every legal NSS in 760 the ISBN Namespace must be a valid ISBN. 762 4. URN Presentation and Transport 764 The URN syntax defines the canonical format for URNs and all URN 765 transport and interchanges MUST take place in this format. Further, 766 all URN-aware applications MUST offer the option of displaying URNs 767 in this canonical form to allow for direct transcription (for example 768 by cut-and-paste techniques). Such applications MAY support -- even 769 in a manner specific to particular URN Namespaces -- display of URNs 770 in a more human-friendly form and MAY use in that context a character 771 set that includes characters that aren't permitted in URN syntax as 772 defined in this RFC (that is, they may replace %-notation by 773 characters in some extended character set in display to humans). 775 Note: Such transformation for the purpose of presentation, if done 776 blindly without NID-specific knowledge of special character usage, 777 might introduce ambiguity, because in the cases described above in 778 the second paragraph of Section 2.5.2, the unescaped and percent- 779 escaped form of the same character might carry different semantics 780 in NSSs of some URN Namespaces. 782 5. Lexical Equivalence of URNs 784 For various purposes such as caching, it is often desirable to 785 determine whether two URNs are "the same" (i.e., designate the same 786 resource), without resolving them. The general-purpose means of 787 doing so is by testing for "lexical equivalence" as defined below. 788 This procedure only can detect mismatches: two lexically different 789 URNs might still be assigned to the same reource -- be it by 790 assignment practice within a single URN Namespace or by a single 791 resource having assigned names from different URN Namespaces. 793 Two URNs are lexically equivalent if they are octet-by-octet equal 794 after the following preprocessing: 795 1. Normalize the case of the leading "urn" scheme name. 796 2. Normalize the case of the NID. 797 3. Normalize the case of any percent-encoding. 798 4. Remove the part of the URI, if present. 799 5. Depending on the objective, perform either step 5a or step 5b: 800 If the objective is related to distinguishing named resources, 801 perform step 5a; if the objective is related to caching specific 802 URN resolution results, perform step 5b. 803 5a. Remove the part of the URI, if present. 804 5b. Reorder the directives in the part of the URI, if 805 present, bringing them into a preferred order. 807 Note that percent-encoding MUST NOT be removed. It is an 808 implementation detail not affecting interoperability whether a 809 function for lexical URN comparison internally prefers normalization 810 (in the first 3 steps above) to lower or to upper case. Similarly, 811 the "preferred order" in step 5b is an implementation choice without 812 impact on interoperability. 814 Some namespaces may define additional lexical equivalences, such as 815 case-insensitivity of the NSS (or parts thereof). Additional lexical 816 equivalences MUST be documented as part of Namespace registration, 817 MUST always only have the effect of eliminating some of the false 818 negatives obtained by the procedure above, i.e., they MUST NOT say 819 that two URNs are not equivalent if the procedure above says they are 820 equivalent. Only URN software that is aware of such additional rules 821 for a specific NID can detect these additional lexical equivalences 823 5.1. Examples of Lexical Equivalence 825 The following hypothetical URN comparisons highlight the lexical 826 equivalence definitions (assuming that the hypothetical 'foo' 827 namespace does not define additional lexical equivalences): 829 1- URN:foo:a123,456 830 2- urn:foo:a123,456 831 3- urn:FOO:a123,456 832 4- urn:foo:A123,456 833 5- urn:foo:a123%2C456 834 6- URN:FOO:a123%2c456 835 7- urn:foo:a123,456?x=y 836 8- urn:foo:a123,456#xyz 838 URNs 1, 2, 3 and 8 are all lexically equivalent, and URN 7 is also 839 lexically equivalent to these if step 5a is applied, but this does 840 not hold if step 5b above is applied instead. in the normalization. 842 URN 4 is not lexically equivalent to any of the other URNs of the 843 above set. URNs 5 and 6 are only lexically equivalent to each other. 845 6. Functional Equivalence of URNs 847 Functional equivalence within a given URN Namespace is determined by 848 the management of URN assignment practices therein and established by 849 the resolvers for that namespace. Thus, it is beyond the scope of 850 this document. Namespace registrations must include guidance on how 851 to determine functional equivalence for that URN Namespace, i.e., 852 when two URNs are identical within a namespace. 854 On the other hand, it is permissible to have two entirely different 855 URNs -- even from different URN Namespaces -- be assigned to a 856 particular resource. This can only be detected by resolving the URNs 857 and analysis of the resolution responses; hence, this is out of scope 858 for this memo. 860 7. The 'urn' URI Scheme 862 At the time of publication of RFC 2141, no formal registration 863 procedure for URI Schemes had been established yet, and so IANA only 864 informally has registered the 'urn' URI Scheme with a reference to 865 [RFC2141]. 867 Therefore, Section 7.1 below contains the URI scheme registration 868 template for the 'urn' scheme, in accordance with RFC 4395 [RFC4395]. 870 Note: In order to be usable as a standalone text (after being 871 extracted from this RFC), the template below does not contain 872 formal anchors to the references listed in Section 11, but instead 873 gives the common document designations in prose. However, for 874 compliance with editorial policy, it needs to be noted here: 876 This registration template refers to RFCs 2196, 2276, 2608, 3401 877 through 3404, 3406bis, 3629 (STD 63), and 3986 (STD 66) ([RFC2169] 878 [RFC2276] [RFC2608] [RFC3401] [RFC3402] [RFC3403] [RFC3404] 879 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] [RFC3629] [RFC3986]). 881 7.1. Registration Template for URI Scheme 'urn' 883 [[ RFC-Editor: Please replace "XXXX" in all instances of "RFC XXXX" 884 below by the RFC number assigned to this document. ]] 885 URI scheme name: urn 887 Status: permanent 889 URI scheme syntax: 891 See Section 2 of RFC XXXX. 893 URI scheme semantics: 895 'urn' URIs, known as Universal Resource Names (URNs), serve as 896 persistent, location-independent, resource identifiers for 897 concrete and abstract objects ("resource") that have network 898 accessible instances and/or metadata. 900 URNs are structured hierarchically into URN Namespaces, the 901 management of which is delegated to namespace-specific 902 authorities. Each such URN Namespace is founded in an independent 903 specification and registered with IANA, following the guidelines 904 and procedures of BCP 66 (at the time of this registration: RFC 905 3406, an update is in progress as RFC 3406bis 906 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]). 908 Encoding considerations: 910 All URNs are ASCII strings conforming to the general URI syntax 911 from STD 66. As described in Sections 2.2 and 2.5.2 of RFC XXXX, 912 there may be characters allowed by the syntax and semantics of the 913 identifier system underlying the URN Namespace but not contained 914 in the US-ASCII charset. Such characters MUST first be 915 represented in Unicode and encoded in UTF-8 according to STD 63. 916 Any octets outside the allowed character set MUST then be percent- 917 encoded. 919 Note that it is perfectly possible that the syntax and semantics 920 of an underlying identifier system does not admit specific 921 characters allowed by the syntax rules in RFC XXXX. 923 Applications/protocols that use this URI scheme: 925 URNs that serve to identify abstract resources for protocol 926 purposes are expected to be recognized directly by the 927 implementations of these portocols. 929 In general, resolution systems for URNs are specified on a per- 930 namespace basis. If appropriate for the namespace, these systems 931 resolve URNs to (possibly multiple) URIs that allow the network 932 access to the identified object or metadata on it. 934 "Architectural Principles of Uniform Resource Name Resolution" 935 (RFC 2276) explains the basic concepts. Some resolution systems 936 laid down in IETF specifications are: 938 * Trivial HTTP-based URN Resolution (RFC 2169) 940 * Dynamic Delegation Discovery System (DDDS, RFCs 3401-3404) 942 * Service Location Protocol (SLPv2, RFC 2608) 944 Interoperability Considerations: 946 Persistence and stability of URNs require appropriate resolution 947 systems. 949 Security Considerations: 951 See Section 8 of RFC XXXX. 953 Contact: 955 The IETF URNbis working group. 956 This registration will be discussed on the following IETF lists: 957 urn and uri-review (AT ietf.org). 959 Author / Change controller: 961 The authors of RFC XXXX. 962 Change control is with the IESG. 964 References: 966 RFC XXXX. 968 Procedures for the specification and registration of URN 969 Namespaces are detailed in BCP 66 (at the time of this writing: 970 RFC 3406; an update is in progress in the URNbis WG as RFC 3406bis 971 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]). 973 8. Security Considerations 975 This document specifies the syntax and general requirements for URNs, 976 which are the specific URIs that use the 'urn' URI scheme. As such, 977 the general security considerations of STD 66 [RFC3986] apply. 978 However, each URN Namespace will have specific security 979 considerations, according to the semantics and usage of the 980 underlying namespace. While some namespaces may assign special 981 meaning to particular characters generically allowed in the Namespace 982 Specific String, any security considerations resulting from such 983 assignment are outside the scope of this document. It is REQUIRED by 984 BCP 66 (currently [RFC3406], to be replaced by RFC 3406bis 985 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]) that the process of 986 registering a namespace identifier include any such considerations. 988 9. IANA Considerations 990 9.1. Registration of URI Scheme 'urn', URN Registry Update 992 IANA is asked to update the existing informal registration of the 993 'urn' URI Scheme by the template in Section 7.1 above and list this 994 RFC as the current normative reference in [IANA-URI]. 996 IANA is asked to add a note to [IANA-URN] that 'urn' is a permanently 997 reserved formal namespace identifier string that cannot be 998 registered, in order to avoid confusion with the 'urn' URI scheme. 1000 [[ RFC-Editor: this para to be deleted before RFC publication. ]] 1001 IANA is asked to again make available the URN Namespace Registry 1002 [IANA-URN] in a generic form (i.e., HTML) at the generic URI given in 1003 the Reference, and to make the XML and TXT versions available from 1004 that HTML version. (This state already had been achieved, but 1005 something seems to have been lost in 2011.) 1007 9.2. URN Query Parameters Registry 1009 IANA is asked to establish a new registry entitled "URN Resolution 1010 Query Parameters" with two sub-registries as described below, 1011 referencing Section 2.3 of this RFC as the authoritative source. 1013 9.2.1. URN Query Keywords Sub-Registry 1015 This registry holds the tokens that can be used in the query 1016 part of URI references to URNs. 1018 Entries capture the following items (that need to be provided by 1019 registration requests: 1021 Keyword - the token to be used in the query part 1023 Purpose - short phrase describing the purpose 1025 Scope - either "global" or "specific" 1027 Defn. Ref. - Reference to defining RFC 1029 Supported by - list of {URN NID, reference} pairs 1030 Keywords of "global" scope are (in principle) open for use with URNs 1031 and URN resolvers for any URN Namespace that choses to adopt it. The 1032 creation or substantive update of such entries requires a document 1033 containing the specification of the query directives using such 1034 keyword, subject to "IETF Review" (cf. BCP 26 [RFC5226]), and the 1035 change control of such entries remains with the IESG. 1037 Keywords of "specific" scope are designed to fulfill the purposes of 1038 a specific URN Namespace or a specific group of URN Namespaces. The 1039 creation or substantive update of such entries requires a 1040 specification document subject to the procedures set out in RFC 1041 3406bis for URN Namespace registration documents; the specification 1042 of the query directives using such keyword can be part of a URN 1043 Namespace registration documents. These entries remain under the 1044 change control of the stakeholders of the URN Namespace(s) given in 1045 the specification document. 1047 Changes in the "Supported by" list of any registry entry is 1048 considered a non-substantive update. Additions will usually be 1049 performed by URN Namespace registration documents (cf. RFC 3406bis), 1050 but to reduce the overhead and encourage usage of this registry, the 1051 maintainers of legacy URN Namespaces (URN NIDs registered before the 1052 publication of this RFC), a URN NID and a non-RFC reference to a 1053 stable document can be added if the maintainers of the URN namespace 1054 demonstrate to IANA the usability of query directives with the 1055 respective keyword; for such requests, IANA may seek advice from the 1056 URN-NID experts as well. 1058 Initial registrations: 1060 Keywd Purpose Scope Defn. Ref. 1061 ----- -------------------------------- -------- ------------------ 1062 s intended URN resolution service global RFC this, s. 2.3.1 1063 c component of structured resource global RFC this, s. 2.3.2 1065 The "Supported by" lists for both entries initially are left empty. 1067 9.2.2. URN Resolution Service Designators Sub-Registry 1069 This registry lists the value tokens that can be used with the "s" 1070 keyword in the query part of URI references to URNs, in order to 1071 identify the desired URN resolution service. 1073 Entries capture the following items (that need to be provided by 1074 registration requests: 1076 Name - mnemomonic for the URN service 1078 Purpose - short phrase describing the service 1080 Status - "std", "exp","provisional", or "deprecated" 1082 Reference - Reference to defining RFC 1084 Registration policy is "RFC required" according to BCP 26 [RFC5226], 1085 where the RFC category required needs to match the desired "Status": 1086 Standards Track for "std", Experimental for "exp". Beyond the 1087 initial assignments performed below, "provisional" status can be 1088 assigned for pending registrations using the procedures of BCP 100 1089 [RFC4020]. IESG Approval ([RFC5226]) is required to modify an entry 1090 to change its status to "deprecated". 1092 In preparation for future work to update that document, the registry 1093 is initially populated with entries derived from Section 4 of RFC 1094 2483 [RFC2483], using uniform spelling of plural forms and marking 1095 all entries as "provisional": 1097 Name Purpose Status Reference 1098 ----- ----------------------------- ----------- ------------------ 1099 I2L URI to URL provisional RFC 2483, sec. 4.1 1100 I2Ls URI to URLs provisional RFC 2483, sec. 4.2 1101 I2R URI to resource provisional RFC 2483, sec. 4.3 1102 I2Rs URI to resources provisional RFC 2483, sec. 4.4 1103 I2C URI to URC provisional RFC 2483, sec. 4.5 1104 I2Cs URI to URCs provisional RFC 2483, sec. 4.6 1105 I2N URI to URN provisional RFC 2483, sec. 4.7 1106 I2Ns URI to URNs provisional RFC 2483, sec. 4.8 1107 I=I URI equal to URI? provisional RFC 2483, sec. 4.9 1109 10. Acknowledgements 1111 This document is heavily based on RFC 2141 by Ryan Moats, which has 1112 laid the foundation for this work; that RFC contained the following 1113 Acknowledgements: 1115 Thanks to various members of the URN working group for comments on 1116 earlier drafts of this document. This document is partially 1117 supported by the National Science Foundation, Cooperative 1118 Agreement NCR-9218179. 1120 This document also heavily relies on and acknowledges the work done 1121 for STD 66 [RFC3986] and earlier RFCs that are being quoted 1122 informally, in particular RFC 1737 [RFC1737] authored by Karen 1123 Sollins and Larry Masinter. The experiences gathered during the 1124 first (more than a) decade of URN usage were also helpful, so 1125 individuals and organizations which have implemented and used URNs 1126 are also acknowledged. In particular, the experience gained with 1127 parties wanting to make use of the URN framework and submit URN 1128 Namespace registration documents, and their desire to obtain the 1129 necessary collected background information has motivated and shaped 1130 the text put into Section 1 of this document. 1132 Many individuals in the URNbis working group have participated in the 1133 detailed discussion of this memo. Particular thanks for detailed 1134 review comments and text suggestions go to Juha Hakala, Mykyta 1135 Yevstifeyev, Peter Saint-Andre, Subramanian Moonesamy, Bengt Neiss, 1136 and Lars Svensson. 1138 11. References 1140 11.1. Normative References 1142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1143 Requirement Levels", BCP 14, RFC 2119, March 1997. 1145 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1146 10646", STD 63, RFC 3629, November 2003. 1148 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1149 Resource Identifier (URI): Generic Syntax", STD 66, 1150 RFC 3986, January 2005. 1152 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1153 Registration Procedures for New URI Schemes", BCP 35, 1154 RFC 4395, February 2006. 1156 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1157 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1158 May 2008. 1160 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1161 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1163 11.2. Informative References 1165 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] 1166 Hoenes, A., "Uniform Resource Name (URN) Namespace 1167 Definition Mechanisms", 1168 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 (work in 1169 progress), October 2012. 1171 [IANA] IANA, "The Internet Assigned Numbers Authority", 1172 . 1174 [IANA-URI] 1175 IANA, "URI Schemes Registry", 1176 . 1178 [IANA-URN] 1179 IANA, "URN Namespace Registry", 1180 . 1182 [RFC0615] Crocker, D., "Proposed Network Standard Data Pathname 1183 syntax", RFC 615, March 1974. 1185 [RFC0645] Crocker, D., "Network Standard Data Specification syntax", 1186 RFC 645, June 1974. 1188 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 1189 Unifying Syntax for the Expression of Names and Addresses 1190 of Objects on the Network as used in the World-Wide Web", 1191 RFC 1630, June 1994. 1193 [RFC1736] Kunze, J., "Functional Recommendations for Internet 1194 Resource Locators", RFC 1736, February 1995. 1196 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 1197 Uniform Resource Names", RFC 1737, December 1994. 1199 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1200 Resource Locators (URL)", RFC 1738, December 1994. 1202 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", 1203 RFC 1808, June 1995. 1205 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1207 [RFC2169] Daniel, R., "A Trivial Convention for using HTTP in URN 1208 Resolution", RFC 2169, June 1997. 1210 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 1211 Name Resolution", RFC 2276, January 1998. 1213 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1214 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1215 August 1998. 1217 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 1218 Necessary for URN Resolution", RFC 2483, January 1999. 1220 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1221 "Service Location Protocol, Version 2", RFC 2608, 1222 June 1999. 1224 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1225 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 1226 June 1999. 1228 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 1229 Scheme Names", BCP 35, RFC 2717, November 1999. 1231 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 1232 "Guidelines for new URL Schemes", RFC 2718, November 1999. 1234 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 1235 IETF URI Planning Interest Group: Uniform Resource 1236 Identifiers (URIs), URLs, and Uniform Resource Names 1237 (URNs): Clarifications and Recommendations", RFC 3305, 1238 August 2002. 1240 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1241 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 1243 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1244 Part Two: The Algorithm", RFC 3402, October 2002. 1246 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1247 Part Three: The Domain Name System (DNS) Database", 1248 RFC 3403, October 2002. 1250 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1251 Part Four: The Uniform Resource Identifiers (URI)", 1252 RFC 3404, October 2002. 1254 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1255 "Uniform Resource Names (URN) Namespace Definition 1256 Mechanisms", BCP 66, RFC 3406, October 2002. 1258 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 1259 Standards Track Code Points", BCP 100, RFC 4020, 1260 February 2005. 1262 Appendix A. Handling of URNs by URL Resolvers/Browsers 1264 The URN syntax has been defined so that URNs can be used in places 1265 where URLs are expected. A resolver that conforms to the current URI 1266 syntax specification [RFC3986] will extract a scheme value of "urn" 1267 rather than a scheme value of "urn:". 1269 An URN MUST be considered an opaque URI by URL resolvers and passed 1270 (with the "urn:" tag) to a URN resolver for resolution. The URN 1271 resolver can either be an external resolver that the URL resolver 1272 knows of, or it can be functionality built into the URL resolver. 1274 However note that, according to RFC 3986, the part of a 1275 URN will be stripped by a resolver client before passing the URN to 1276 the resolver, and subsequently be applied to the returned result -- 1277 in the manner specified for the returned media type. 1279 To avoid confusion of users, a URL browser SHOULD display the 1280 complete URN (including the "urn:" tag) to ensure that there is no 1281 confusion between URN Namespace identifiers and URI Scheme names. 1283 Appendix B. Collected ABNF (Informative) 1285 As a service to implementers specifically interested in URN syntax, 1286 the complete ABNF for URNs is collected here, including the 1287 referenced rules from [RFC5234] and [RFC3986]. In case of 1288 (unexpected) inconsistencies, these documents remain normative for 1289 the respective productions. 1291 URNs conform to the variant of the general URI syntax 1292 specified in Section 3 of [RFC3986] : 1294 URI = scheme ":" path-rootless [ "?" query ] [ "#" fragment ] 1296 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 1297 path-rootless = segment-nz *( "/" segment ) 1298 query = *( pchar / "/" / "?" ) 1299 fragment = *( pchar / "/" / "?" ) 1301 segment-nz = 1*pchar 1302 segment = *pchar 1303 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 1305 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 1306 pct-encoded = "%" HEXDIG HEXDIG 1307 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 1308 / "*" / "+" / "," / ";" / "=" 1310 In the case of URNs, the above rules are subject to more specific 1311 restrictions, specified in Section 2 of this RFC: 1313 scheme = "urn" 1314 ; specific, fixed (assigned) value 1316 urn-path = NID ":" NSS 1317 ; to be superimposed on , 1318 ; which needs to be only 1320 NID = ( ALPHA / DIGIT ) 1*31( ALPHA / DIGIT / "-" ) 1321 ; RFC 3406[bis] contains more specific rules 1323 NSS = 1*pchar 1324 ; or equivalent: NSS = segment-nz 1326 urn-query = directive *( "&" directive) 1327 ; to be superimposed on 1329 directive = keywd "=" value 1330 keywd = ALPHA *( ["-"] (ALPHA / DIGIT)) 1331 value = *v-pchar 1333 v-pchar = unreserved / pct-encoded / v-subdels 1334 v-subdels = "!" / "$" / "'" / "(" / ")" 1335 / "*" / "+" / "," / ";" / "=" 1336 ; this is equivalent to except "&" 1337 / ":" / "@" / "/" / "?" 1338 ; plus the extra characters allowed in 1339 ; and for , as per RFC 3986 1341 The above rules make use of the following "Core Rules" from Appendix 1342 B.1 of [RFC5234] : 1344 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 1345 DIGIT = %x30-39 ; 0-9 1346 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 1348 Appendix C. Breakdown of NSS Syntax Evolution since RFC 2141 1349 (Informative) 1351 In order to make visible the detailed migration path from RFC 2141 1352 and the influence of the evolution of URI syntax from RFC 2396 to RFC 1353 3986 on it, this appendix provides a highly annotated and expanded 1354 version of the NSS syntax provided in Section 2.2: 1356 NSS = 1*pchar ; or equivalent: NSS = segment-nz 1358 In particular, the breakdown below serves to provide evidence of that 1359 this syntax correctly reflects the addition of "&" and "~" to the 1360 repertoire of characters allowed in the NSS portion of URNs 1361 previously allowed by RFC 2141; it expands on the syntax specified in 1362 RFC 2141 after translation to standard ABNF. 1364 NSS = 1*URN-char 1366 URN-char = trans / pct-encoded 1367 ; Note that from RFC 3986 here replaces the 1368 ; explicit, expanded form used in RFC 2141. 1370 trans = ALPHA / DIGIT / u-other 1371 ; Note that RFC 2141's has been disambiguated here 1372 ; into . 1373 ; RFC 2141 also said: 1374 ; / reserved 1375 ; This caused an ambiguity in RFC 2141 with respect to "%", which 1376 ; now is resolved here by omission of this dangling alternative. 1377 ; 1378 ; After adoption of the generic URI syntax from RFC 3986, there 1379 ; is no more need to deal here with the higher-level separator 1380 ; characters "/", "?", and "#" contained in 1381 ; (beyond "%", which is fully taken care of by ), 1382 ; which are part of RFC 3986's , as shown below. 1384 ; From RFC 2141: 1385 ; reserved = '%" / "/" / "?" / "#" ; SIC! 1386 ; ^ ^ 1388 u-other = ":" / "@" 1389 ; those from RFC 3986 1390 ; specifically allowed in . 1391 ; From RFC 3986: 1392 ; gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" 1394 / "!" / "$" / "'" / "(" / ")" 1395 / "*" / "+" / "," / ";" / "=" 1396 ; this is RFC 3986 except "&". 1397 ; From RFC 3986: 1398 ; sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 1399 ; / "*" / "+" / "," / ";" / "=" 1400 ; The URNbis WG arrived at unanimous consensus that "&" can be 1401 ; allowed without harm to backward compatibility for existing 1402 ; URN Namespaces. 1404 / "-" / "." / "_" ; except "~" 1405 ; From RFC 3986: 1407 ; unreserved = ALPHA / DIGIT 1408 ; / "-" / "." / "_" / "~" 1409 ; The URNbis WG arrived at unanimous consensus that "~" can be 1410 ; allowed without harm to backward compatibility for existing 1411 ; URN Namespaces. 1413 ; Since we now allow "&" and "~" , becomes , 1414 ; greatly simplifying the syntax rules and parsers! 1416 ; From RFC 3986: 1417 ; segment-nz = 1*pchar 1418 ; pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 1420 Appendix D. Changes since RFC 2141 (Informative) 1422 D.1. Essential Changes from RFC 2141 1424 [[ RFC-Editor: please remove the Appendix D.1 headline and all 1425 subsequent subsections starting with Appendix D.2. ]] 1427 Expanded Introduction to cover background material frequently 1428 requested by interested parties not well acquainted with RFCs and 1429 past/present work in the IETF, in particular prospective URN 1430 Namespace stakeholders and applicants for URN Namespace 1431 registrations. The material included also serves to avoid normative 1432 downrefs to legacy RFCs that are very unlikely to be progressed on 1433 the Standards Track in the foreseeable future. 1435 Document references updated and split; Normative References now only 1436 to Full Internet Standards to allow for future progress of this memo 1437 on the IETF Standards Track. 1439 Formal syntax now specified using ABNF (STD 68), using productions 1440 from Generic URI Syntax (STD 66) and STD 68. 1442 NID Syntax slightly more restrictive than in RFC 2141 (compatible 1443 with existing and in-progress NID registrations). 1445 NSS syntax now allows "&" and "~" to align URN syntax with generic 1446 rule from STD 66; an ambiguity in the formal rules and 1447 incompatibilities between the formal rules and the prose description 1448 in RFC 2141 have been straightened out ("%" no more allowed outside 1449 percent-encoding triples, other characters no more 1450 admitted by formal syntax rules). 1452 Use of query and fragment part with URNs now specified, mostly by 1453 reference to STD 66. Syntactical pattern for query part defined; 1454 IANA registry for query keywords in URN references established. 1456 This document also performs the outstanding formal registration of 1457 the 'urn' URI scheme. 1459 Supplemental material in Appendices documents considerations and 1460 decisions made in the development of this memo. 1462 D.2. Changes from RFC 2141 to Individual Draft -00 1464 Abstract amended: URI scheme, replacement for 2141, point to 3406. 1465 Use contemporary boilerplate. Added transient "Discussion" section. 1467 s1: added new 1st para (URI scheme) and 3rd para (hierarchy). 1468 s1.1 (Historical Perspective) added for background & motivation. 1469 s1.2 (Objective) added. 1470 s1.3 (2119 keywords) added -- used now throughout normative text. 1472 s2 (URN Syntax): Shifted from BNF to ABNF; explain relationship to 1473 3986 and gaps, how the gaps could be bridged, distinguish between URI 1474 generics and URN specifics; got rid of references to immature 1475 documents (1630, 1737). 1476 s2.1 (NID syntax): Use ABNF and RFC 5234 terminals (core rules); 1477 removed reference to an old draft of 2396; clarified prohibition to 1478 use "urn" as NID. 1479 s2.2 (NSS syntax): Shifted from BNF to ABNF; made ABNF consistent 1480 with subsequent textual description; exposition much expanded, 1481 showing relationship with 3986 and resulting incompatibilities; 1482 proposed how to bridge gaps, to make parsing more uniform among URIs; 1483 updated i18n considerations and pointer to UTF-8 specification. 1484 s.2.3, s2.3.*: reworked and much expanded, along the grouping of 1485 delimiter characters from 3986 in new s2.3.1 (including old s.2.3.2); 1486 made text fully consistent with ABNF in s2.2; consistent usage of 1487 term "percent-encoded"; old s.2.3.1 became s2.3.2; old s3.4 became 1488 s3.3.3, providing complete, annotated list of excluded characters, 1489 ordered by ascending code point; and restating design decisions 1490 needed to be made to close gaps to 3986. 1492 s3 through s6: only minor editorial changes. 1494 s7: formal registration of 'urn' URI scheme added, using 4395 1495 template. 1497 s8: Security Cons. slightly amended. 1499 s9: new: IANA Cons. added wrt s7.1 and prohibition of NID "urn". 1501 s10: Acknowledgments amended. 1503 s11: References split into Normative and Informative; updated refs 1504 and added many; only FS and BCP allowed as Normative Refs to further 1505 promotion of document. 1507 Added Appendices A through D. 1509 D.3. Changes from Individual Draft -00 to -02 1511 Updated "Discussion" on front page to point to dedicated urn list. 1513 Numerous editorial improvements and additions for clarification, in 1514 particular in the Introduction. No technical changes. 1516 More Informative References; missing details supplied in D.2. 1518 D.4. Changes from Individual Draft -02 to WG Draft -00 1520 Added new s1.2 to Introduction, with excerpts from RFC 1737 to 1521 provide background on URN functional and syntax requirements. 1522 Renumbered previous s1.2 and s1.3 to s1.3 and s1.4, respectively. 1524 Supplied text in s2 regarding the envisioned use of query and 1525 fragment parts, based on various discussion -- including a 1526 preliminary evaluation in PersID. 1528 Changed "SHOULD never" to "MUST NOT" for NUL character in NSS. 1530 Various editorial and grammar fixes; corrected STD / BCP numbers. 1532 D.5. Changes from WG Draft -00 to WG Draft -01 1534 Reflect WG consensus on adding "&" and "~" to the set of characters 1535 allowed in the NSS part of URNs, thus aligning URN syntax with 1536 generic URI syntax from RFC 3986. 1538 Moved breakdown of NSS syntax evolution from s2.2 to new Appendix C. 1540 Avoid "[URN] character set" in favor of "character repertoire" to 1541 minimize potential clashes with IETF terminology on charsets. 1543 s2.3.3: URN recognition in text documents is regarded out of scope. 1545 The previous version was ambiguous on whether eventual query and/or 1546 fragment parts were regarded as part of the NSS; after closer 1547 inspection of the syntax, clarification has been added that the syntax is indeed superimposed on the ABNF rule for 1549 URNs, and hence does not cover the trailing higher level parts 1550 (query, fragment) according to the URI syntax. 1552 Filled in Appendix B contents. 1554 Numerous editorial and grammar improvements. 1556 D.6. Changes from WG Draft -01 to WG Draft -02 1558 Added note at the beginning of Section 1.3 highlighting the purpose 1559 of this section. The URNbis charter excludes a revision of RFC 1738, 1560 and hence the changes suggested on the list to alter and update this 1561 section have been dismissed. 1563 Added hint to URN Namespace designers in Section 2 that ":" is 1564 customarily used in URN Namespaces to provide further level(s) of 1565 hierarchical subdivision of NSSs. 1567 Reworked text on fragment identification issues and resulting 1568 specification, mostly based on Juha Hakala's evaluation of the 1569 consensus evolving from the list discussion. 1571 Modified ABNF rule for NIDs to better align it with rules for similar 1572 identifiers used in IETF protocols. The new rule now prohibits a 1573 trailing hyphen, but defers further restricting rules on NID syntax 1574 (based on the kind of NID) to RFC 3406bis. 1576 More clearly documented and marked (still open / already closed) 1577 ISSUES. The related text will be removed in the next draft version, 1578 whence it should have been transferred into the IETF issue tracking 1579 system. 1581 Text of Section 3 revised, based on Juha's suggestion. 1583 In Section 5, added removal of part (but not part) 1584 to canonicalization steps for the purpose of determining lexical 1585 equivalence of URNs (Juha's comment). Also added examples showing 1586 this. 1588 Elaborated a bit more on Encoding Consideration in the URI Scheme 1589 registration template (Juha's comments). 1591 Numerous editorial corrections and improvements. 1593 D.7. Changes from WG Draft -02 to WG Draft -03 1595 Added text in s1.1 to reflect a comment from SM on other, legacy 1596 interpretations of "URN". 1598 Added note in old s1.2 to reflect importance of the name binding 1599 established by a URN (derived from list discussion on other topic, 1600 Keith Moore et al.). 1601 However, (despite comments from SM and PSA) preserved excerpts there 1602 to keep document self-contained and avoid normative down-references 1603 (as discussed during WG chartering process and pointed out in the 1604 third para of old s1.3). Doing so should also help to avoid another 1605 future recurrence of the discussion on these topics that has consumed 1606 a lot of resources unnecessarily during the WG formation process. 1608 Swapped s1.2 and s1.3 (note from SM); however, for logical reasons, 1609 motivation (part of s1.1) needs to stay in the text before the 1610 objectives derived thereof (now s1.2). 1612 Material on query part enhanced (new subsection 2.3); structure of 1613 query part formally specified with a rather liberal syntax (could be 1614 more restrictive, if WG prefers); IANA registry of URN query keywords 1615 established, with two initial entries for the global scope "s" and 1616 "c" keywords now specified in s2.3.1 and s2.3.2. 1618 To avoid further confusion (as seen on the list discussion), this I-D 1619 uses the term "fragment" only for the trailing component in the 1620 Generic URI Syntax and the semantics associated with it in RFC 3986; 1621 otherwise this I-D talks about "components" of structured resources. 1623 Material on fragment part heavily revised and stripped down, put in 1624 new subsection 2.4. New text is intended to reflect least common 1625 denominator of list discussion; i.e., mostly just enable usage by 1626 specific URN Namespace and otherwise point to RFC 3986 and RFC 1627 3406bis. 1628 Namespace designers now have three options to design-in component 1629 resource designation (if warranted for the namespace), whichever is 1630 the best fit for their underlying identifier system: (1) media- 1631 specific designation using fragment part, (2) media-independent, 1632 abstract designation using query part (to be dealt with by resolution 1633 system, not resolution client), and (3) media-independent designation 1634 via assignment of distinct NSSs to component resources. 1635 (That is being elaborated upon to a greater extent in the -03 version 1636 of the rfc3406bis I-D.) 1638 Added text to percent-encoding considerations (Bengt Neiss' 1639 concerns). 1641 Amended text on support of existing identifier systems (s3), based on 1642 various comments received. 1644 Revised part of text in s5 and s6 on lexical/functional equivalence 1645 to reflect the new specification for query and fragment (new s2.3, 1646 s2.4) and to address several comments received; changed s5.1 1647 accordingly. 1649 In spite of the challenges raised by serious evidence of improper 1650 management practices for the ISBN system and hence the URN:ISBN 1651 Namespace (Lars Svensson), the I-D still contains one (hypothetical) 1652 example based on URN:ISBN; this is being thought acceptable because 1653 it is in the tradition of earlier documents and we can expect that 1654 every potential reader of the memo will have an understanding what 1655 ISBNs are for (or should be). 1657 Modified title of s7.1 to avoid clash with new s9.1. Added IANA 1658 Considerations for "URN Query Parameters" registries (s9.2). 1660 Acknowledgements expanded. 1662 Amended Appendix A with text regarding usage. 1664 Filled in details in Appendix D.1; added this Appendix D.7. 1666 Former Appendix E (guide to IETF document repositories) and pointer 1667 to it removed (comment from SM). 1669 Multiple editorial enhancements and fixes. 1671 Author's Address 1673 Alfred Hoenes (editor) 1674 TR-Sys 1675 Gerlinger Str. 12 1676 Ditzingen D-71254 1677 Germany 1679 EMail: ah@TR-Sys.de