idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-07.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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 23, 2014) is 3739 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) == Outdated reference: A later version (-09) exists of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-urnbis-rfc3406bis-urn-ns-reg' -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 URNBIS P. Saint-Andre, Ed. 3 Internet-Draft 4 Obsoletes: 2141 (if approved) January 23, 2014 5 Intended status: Standards Track 6 Expires: July 27, 2014 8 Uniform Resource Name (URN) Syntax 9 draft-ietf-urnbis-rfc2141bis-urn-07 11 Abstract 13 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 14 that is intended to serve as a persistent, location-independent 15 resource identifier. This document defines the canonical syntax for 16 URIs under the "urn" scheme, guidelines for URN namespaces, 17 requirements for URN presentation and transmission, and methods for 18 determining URN equivalence. This document obsoletes RFC 2141. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 27, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4.1. Namespace Identifier Syntax . . . . . . . . . . . . . . . 4 71 4.2. Namespace Specific String Syntax . . . . . . . . . . . . 4 72 4.3. Query Component and Fragment Identifier Component . . . . 4 73 5. URN Presentation and Transport . . . . . . . . . . . . . . . 5 74 6. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 5 75 6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Handling of URNs by URI Processors . . . . . . . . . . . . . 6 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Appendix A. Changes from RFC 2141 . . . . . . . . . . . . . . . 8 84 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 9 85 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 91 [RFC3986] that is intended to serve as a persistent, location- 92 independent resource identifier. This document defines the canonical 93 syntax for URIs under the "urn" scheme, guidelines for URN 94 namespaces, requirements for URN presentation and transmission, and 95 methods for determining URN equivalence. 97 URNs were originally defined in [RFC2141]. The goal of this document 98 is to specify URNs with the smallest reasonable set of changes from 99 the original definition while ensuring consistency with the updated 100 specification of URIs in [RFC3986]. 102 This document obsoletes RFC 2141. 104 2. Terminology 106 Several important terms used in this document are defined in the URI 107 specification [RFC3986]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 [RFC2119]. 114 3. Requirements 116 The requirements for URNs are specified in [RFC1737]. This document 117 does not modify or update those requirements. 119 4. URN Syntax 121 The syntax for a URN is defined as follows using the Augmented 122 Backus-Naur Form (ABNF) as specified in [RFC5234]. 124 namestring = assigned-name [ "?" query ] [ "#" fragment ] 125 ; 126 ; query and fragment are defined in RFC 3986 127 ; 128 assigned-name = "urn" ":" NID ":" NSS 129 ; 130 ; the URI scheme ("urn") is case-insensitive 131 ; 132 NID = (alphanum) 0*30(ldh) (alphanum) 133 ; 134 ; alphanum is defined in RFC 3986 135 ; 136 ldh = alphanum / "-" 137 NSS = 1*(pchar) 138 ; 139 ; pchar is defined in RFC 3986 140 ; 142 The following sections describe provide additional information about 143 these rules. 145 4.1. Namespace Identifier Syntax 147 The syntax here is slightly more restrictive than what was defined in 148 [RFC2141], since it forbids the character "-" at the end of a NID. 150 NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent). 152 4.2. Namespace Specific String Syntax 154 Depending on the rules governing a namespace, names that are valid in 155 a namespace might contain characters that are not allowed in URNs 156 according to the "pchar" rule (e.g., characters outside the ASCII 157 range or characters that are reserved in URIs, such as "/", "?", and 158 "#"). Such a string MUST be translated into a conformant NSS before 159 using it as a protocol element or otherwise passing it on to other 160 applications. Translation is done by percent-encoding each 161 disallowed character using the method defined in Section 2.1 of 162 [RFC3986]. Note that the "%" character is allowed only for the 163 purpose of percent-encoding. 165 If a namespace designates one or more characters conforming to the 166 "pchar" rule as having special meaning for that namespace (e.g., "@") 167 and the namespace also uses that character in a literal sense, when 168 used in a literal sense the character MUST be percent-encoded (e.g., 169 "%40"). For related considerations with regard to NID registration, 170 see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 172 4.3. Query Component and Fragment Identifier Component 174 The URI specification [RFC3986] allows a query component, a fragment 175 identifier component, or both after the path component of a URI, 176 where the character '?' is used as a separator to denote the 177 beginning of the query component and the character '#' is used as a 178 separator to denote the beginning of the fragment identifier 179 component. The original URN syntax specification [RFC2141] reserved 180 the '?' and '#' characters for future developments. This 181 specification aligns URN syntax with URI syntax by allowing the query 182 component and fragment identifier component after (not within) the 183 Namespace Specific String (NSS). 185 This specification does not define the applicability and semantics of 186 the query component or the fragment identifier component in URNs. 187 Additional specifications might establish these matters for URN- 188 related services (such as resolution) or for individual URN 189 namespaces. For example, it is possible that the query component 190 might be used in requests to URN resolution services, or that the 191 fragment identifier component might be used to distinguish the 192 integral parts of resources named by URNs. However, defining such 193 usage is left to specifications for URN resolution services, 194 namespace registration requests and specifications for individual 195 namespaces (which might use some namespace-specific syntax instead of 196 the URI fragment identifier component), and other appropriate 197 documentation (such as policy documents governing the management of a 198 given URN namespace). 200 Although URN assignment is a managed process (see 201 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]), the query component or 202 fragment identifier component can be appended after the NSS once a 203 URN has been assigned in accordance with the rules for a given 204 namespace. 206 5. URN Presentation and Transport 208 The URN syntax defines the canonical format for URNs. When URNs are 209 transported and exchanged, they MUST be represented in this format. 210 Further, all URN-aware applications MUST offer the option of 211 displaying URNs in this canonical form to allow for direct 212 transcription (for example by cut and paste techniques). Such 213 applications might support display of URNs in a more human-friendly 214 form and might use a character set that includes characters that are 215 not permitted in URN syntax as defined in this specification (e.g., 216 when displaying URNs to humans, such applications might replace 217 percent-encoded strings with characters in an extended character set 218 such as [UNICODE]). 220 6. Equivalence of URNs 222 6.1. Procedure 224 For various purposes such as caching, often it is desirable to 225 determine if two URNs are "the same". This is done by testing for 226 equivalence (see Section 6.1 of [RFC3986]). 228 Two URNs are equivalent if they are octet-by-octet equal after 229 applying case normalization (as specified in Section 6.2.2.1 of 230 [RFC3986]) to the following constructs: 232 1. the URI scheme "urn" 234 2. the NID 236 3. any percent-encoded characters (see Section 2.1 of [RFC3986]) in 237 the NSS 239 Percent-encoded characters MUST NOT be decoded, i.e., percent- 240 encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) 241 MUST NOT be applied. 243 If a query component, fragment identifier component, or both have 244 been appended to the assigned URN, they MUST be ignored for purposes 245 of determining equivalence. 247 URN namespaces MAY define additional rules for equivalence, such as 248 case-insensitivity of the NSS (or parts thereof). Such rules MUST 249 always have the effect of eliminating some of the false negatives 250 obtained by the procedure above and MUST NOT result in treating two 251 URNs as not equivalent if the procedure here says they are 252 equivalent. For related considerations with regard to NID 253 registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 255 6.2. Examples 257 The following URN comparisons (which use the "example" NID defined in 258 [RFC6963]) highlight the equivalence rules: 260 1. URN:example:a123,456 262 2. urn:example:a123,456 264 3. urn:EXAMPLE:a123,456 266 4. urn:example:A123,456 268 5. urn:example:a123%2C456 270 6. URN:EXAMPLE:a123%2c456 272 URNs 1, 2, and 3 are equivalent. URN 4 is not equivalent to any of 273 the other URNs in the above set. URNs 5 and 6 are equivalent only to 274 each other. 276 7. Handling of URNs by URI Processors 278 The URN syntax has been defined so that URNs can be used in places 279 where URIs are expected. A resolver that conforms to the URI 280 specification [RFC3986] will extract a scheme of "urn" rather than a 281 scheme value of "urn:". 283 A URN MUST be considered an opaque URI by URI resolvers and passed 284 (with the "urn" scheme) to a URN resolver for resolution. The URN 285 resolver can either be an external resolver that the URI resolver 286 knows of, or it can be functionality built-in to the URI resolver. 288 To minimize user confusion, a URI browser SHOULD display the complete 289 URN (including the "urn" scheme) to ensure that there is no confusion 290 between URN namespace identifiers and URI scheme identifiers (e.g., a 291 URI beginning with "urn:xmpp:" [RFC4854] is very different from a URI 292 beginning with "xmpp:" [RFC5122]). 294 8. IANA Considerations 296 This section formally registers a URI scheme of 'urn'. 298 [Note to RFC Editor: please replace "XXXX" with the number assigned 299 to this document upon publication.] 301 URI Scheme Name: urn 303 Status: permanent 305 URI Scheme Syntax: See Section 4 of RFC XXXX. 307 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 308 Names, which are persistent, location-independent resource 309 identifiers. 311 Encoding Considerations: See Section 4.2 of RFC XXXX. 313 Applications/Protocols That Use This URI Scheme Name: Uniform 314 Resource Names are used in a wide variety of applications, 315 including bibliographic reference systems and as names for 316 Extensible Markup Language (XML) namespaces. 318 Interoperability Considerations: There are no known interoperability 319 concerns related to use of the 'urn' URI scheme. 321 Security Considerations: See Section 9 of RFC XXXX. 323 Contact: URNBIS WG [mailto:urn@ietf.org] 325 Author/Change Controller: This scheme is registered under the IETF 326 tree. As such, the IETF maintains change control. 328 References None. 330 9. Security Considerations 332 This document specifies the syntax for URNs. While some namespace 333 resolvers might assign special meaning to certain of the characters 334 of the Namespace Specific String, any security considerations 335 resulting from such assignment are outside the scope of this 336 document. For related considerations with regard to NID 337 registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 339 10. References 341 10.1. Normative References 343 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] 344 Saint-Andre, P., "Uniform Resource Name (URN) Namespace 345 Definition Mechanisms", draft-ietf-urnbis-rfc3406bis-urn- 346 ns-reg-07 (work in progress), November 2013. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 352 Resource Identifier (URI): Generic Syntax", STD 66, RFC 353 3986, January 2005. 355 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 356 Specifications: ABNF", STD 68, RFC 5234, January 2008. 358 10.2. Informative References 360 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 361 Uniform Resource Names", RFC 1737, December 1994. 363 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 365 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 366 for Extensions to the Extensible Messaging and Presence 367 Protocol (XMPP)", RFC 4854, April 2007. 369 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 370 (IRIs) and Uniform Resource Identifiers (URIs) for the 371 Extensible Messaging and Presence Protocol (XMPP)", RFC 372 5122, February 2008. 374 [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 375 for Examples", BCP 183, RFC 6963, May 2013. 377 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 378 6.3", 2013, 379 . 381 Appendix A. Changes from RFC 2141 383 This document makes the following substantive changes from [RFC2141]: 385 o Allows the URI query component after the URN as assigned. 387 o Allows the URI fragment identifier component after the URN as 388 assigned. 390 o Disallows "-" at the end of a NID. 392 o Allows the "~" and "&" characters in an NSS. 394 o Formally registers 'urn' as a URI scheme. 396 Appendix B. Contributors 398 Ryan Moats authored RFC 2141, which provided the basis for this 399 document. 401 Appendix C. Acknowledgements 403 Many thanks to Leslie Daigle, Martin Duerst, Juha Hakala, Ted Hardie, 404 Alfred Hoenes, John Klensin, Keith Moore, Julian Reschke, Lars 405 Svensson, and other participants in the URNBIS WG for their input. 407 Author's Address 409 Peter Saint-Andre (editor) 411 Email: ietf@stpeter.im