idnits 2.17.1 draft-ietf-urnbis-rfc2141bis-urn-04.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 (November 27, 2012) is 4167 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 informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 0 errors (**), 0 flaws (~~), 2 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 Cisco Systems, Inc. 4 Obsoletes: 2141 (if approved) R. Moats 5 Intended status: Standards Track November 27, 2012 6 Expires: May 31, 2013 8 Uniform Resource Name (URN) Syntax 9 draft-ietf-urnbis-rfc2141bis-urn-04 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. The general class of URNs is differentiated 16 from all other URIs through the use of the 'urn' URI scheme. This 17 document defines the canonical syntax for URNs, guidelines for URN 18 namespaces, requirements for URN presentation and transmission, and 19 methods for determining URN equivalence. This document obsoletes RFC 20 2141. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 31, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 5. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5.1. Namespace Identifier Syntax . . . . . . . . . . . . . . . . 5 74 5.2. Namespace Specific String Syntax . . . . . . . . . . . . . 5 75 6. URN Presentation and Transport . . . . . . . . . . . . . . . . 6 76 7. Lexical Equivalence in URNs . . . . . . . . . . . . . . . . . . 6 77 7.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 8. Functional Equivalence in URNs . . . . . . . . . . . . . . . . 7 80 9. Handling of URNs by URI Processors . . . . . . . . . . . . . . 7 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 86 Appendix A. Changes from RFC 2141 . . . . . . . . . . . . . . . . 9 87 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 93 [RFC3986] that is intended to serve as a persistent, location- 94 independent resource identifier. The general class of URNs is 95 differentiated from all other URIs through the use of the 'urn' URI 96 scheme. This document defines the canonical syntax for URNs, 97 guidelines for URN namespaces, requirements for URN presentation and 98 transmission, and methods for determining URN equivalence. 100 URNs were originally defined in [RFC2141]. The goal of this document 101 is to specify URNs with the smallest reasonable set of changes from 102 the original definition while ensuring consistency with the updated 103 specification of URIs in [RFC3986]. If approved, this document will 104 obsolete RFC 2141. 106 The discussion venue for this specification is the mailing list of 107 the URNBIS Working Group; further information can be found at 108 . 110 2. Discussion Venue 112 The discussion venue for this document is mailing list of the URNBIS 113 WG; visit for 114 subscription and archive information. 116 3. Terminology 118 Several important terms used in this document are defined in the URI 119 specification [RFC3986]. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. 126 4. Requirements 128 The requirements for URNs are specified in [RFC1737]. This document 129 does not modify or update those requirements. 131 5. URN Syntax 133 The syntax for a URN is defined as follows using the Augmented 134 Backus-Naur Form (ABNF) as specified in [RFC5234]. 136 URN = "urn" ":" NID ":" NSS 137 ; 138 ; the URI scheme ("urn") is case-insensitive 139 ; 140 NID = (alphanum) 0*30(ldh) (alphanum) 141 ; 142 ; alphanum is defined in RFC 3986 143 ; 144 ldh = alphanum / "-" 145 NSS = 1*(pchar) 146 ; 147 ; pchar is defined in RFC 3986 148 ; 150 The following sections describe provide additional information about 151 these rules. 153 5.1. Namespace Identifier Syntax 155 The syntax here is slightly more restrictive than what was defined in 156 [RFC2141], since it forbids the hyphen character "-" at the end of a 157 NID. 159 NIDs are case insensitive (e.g., "ISBN" and "isbn" identify the same 160 namespace). 162 5.2. Namespace Specific String Syntax 164 Depending on the rules governing a namespace, names that are valid in 165 a namespace might contain characters that are not allowed in URNs 166 according to the urnchar rule (e.g., characters outside the ASCII 167 range or characters that are reserved in URIs, such as "/", "?", and 168 "#"). Such a string MUST be translated into a conformant NSS before 169 using it as a protocol element or otherwise passing it on to other 170 applications. Translation is done by percent-encoding each 171 disallowed character using the method defined in [RFC3986]. 173 The "%" character is allowed only for the purpose of percent- 174 encoding. 176 If a namespace designates one or more characters conforming to the 177 urnchar rule as having special meaning for that namespace (e.g., "@") 178 and the namespace also uses that character in a literal sense, when 179 used in a literal sense the character MUST be percent-encoded (e.g., 180 "%40"). For related considerations with regard to NID registration, 181 see [RFC3406]. 183 6. URN Presentation and Transport 185 The URN syntax defines the canonical format for URNs. All URN 186 transport and interchanges MUST take place in this format. Further, 187 all URN-aware applications MUST offer the option of displaying URNs 188 in this canonical form to allow for direct transcription (for example 189 by cut and paste techniques). Such applications might support 190 display of URNs in a more human-friendly form and might use a 191 character set that includes characters that are not permitted in URN 192 syntax as defined in this RFC (i.e., when displaying URNs to humans, 193 such applications might replace percent-encoded strings with 194 characters in an extended character set such as Unicode). 196 7. Lexical Equivalence in URNs 198 7.1. Procedure 200 For various purposes such as caching, often it is desirable to 201 determine if two URNs are "the same". This is done by testing for 202 "lexical equivalence". 204 Two URNs are lexically equivalent if they are octet-by-octet equal 205 after the following preprocessing rules: 207 1. normalize the case of the URI scheme "urn" 208 2. normalize the case of the NID 209 3. normalize the case of any percent-encoding 211 Note: Percent-encoded characters MUST NOT be decoded. 213 URN namespaces MAY define additional rules for lexical equivalence, 214 such as case-insensitivity of the NSS (or parts thereof). Such rules 215 MUST always have the effect of eliminating some of the false 216 negatives obtained by the procedure above and MUST NOT result in 217 treating two URNs as not equivalent if the procedure here says they 218 are equivalent. For related considerations with regard to NID 219 registration, see [RFC3406]. 221 7.2. Examples 223 The following URN comparisons highlight the lexical equivalence 224 rules: 226 1. URN:foo:a123,456 227 2. urn:foo:a123,456 228 3. urn:FOO:a123,456 229 4. urn:foo:A123,456 230 5. urn:foo:a123%2C456 231 6. URN:FOO:a123%2c456 233 URNs 1, 2, and 3 are lexically equivalent. URN 4 is not lexically 234 equivalent to any of the other URNs in the above set. URNs 5 and 6 235 are lexically equivalent only to each other. 237 8. Functional Equivalence in URNs 239 Functional equivalence is determined within a given namespace and 240 managed by resolvers for that namespace, and thus is beyond the scope 241 of this document. For related considerations with regard to NID 242 registration, see [RFC3406]. 244 9. Handling of URNs by URI Processors 246 The URN syntax has been defined so that URNs can be used in places 247 where URIs are expected. A resolver that conforms to the URI 248 specification [RFC3986] will extract a scheme of "urn" rather than a 249 scheme value of "urn:". 251 A URN MUST be considered an opaque URI by URI resolvers and passed 252 (with the "urn" scheme) to a URN resolver for resolution. The URN 253 resolver can either be an external resolver that the URI resolver 254 knows of, or it can be functionality built-in to the URI resolver. 256 To minimize user confusion, a URI browser SHOULD display the complete 257 URN (including the "urn" scheme) to ensure that there is no confusion 258 between URN namespace identifiers and URL scheme identifiers. 260 10. Security Considerations 262 This document specifies the syntax for URNs. While some namespaces 263 resolvers may assign special meaning to certain of the characters of 264 the Namespace Specific String, any security consideration resulting 265 from such assignment are outside the scope of this document. For 266 related considerations with regard to NID registration, see 267 [RFC3406]. 269 11. IANA Considerations 271 This section formally registers a URI scheme of 'urn'. 273 [Note to RFC Editor: please change "XXXX" to the number assigned to 274 this document upon publication.] 276 URI Scheme Name: urn 277 Status: permanent 278 URI Scheme Syntax: See Section 4 of RFCXXXX. 279 URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource 280 Names, which are persistent, location-independent resource 281 identifiers. 282 Encoding Considerations: See Section 4.2 of RFCXXXX. 283 Applications/Protocols That Use This URI Scheme Name: Uniform 284 Resource Names are used in a wide variety of applications, 285 including bibliographical reference systems and as names for 286 Extensible Markup Language (XML) namespaces. 287 Interoperability Considerations: There are no known interoperability 288 concerns related to use of the 'urn' URI scheme. 289 Security Considerations: See Section 9 of RFCXXXX. 290 Contact: URNBIS WG [mailto:urn@ietf.org] 291 Author/Change Controller: This scheme is registered under the IETF 292 tree. As such, the IETF maintains change control. 293 References None. 295 12. References 297 12.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 303 Resource Identifier (URI): Generic Syntax", STD 66, 304 RFC 3986, January 2005. 306 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 307 Specifications: ABNF", STD 68, RFC 5234, January 2008. 309 12.2. Informative References 311 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 312 Uniform Resource Names", RFC 1737, December 1994. 314 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 316 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 317 "Uniform Resource Names (URN) Namespace Definition 318 Mechanisms", BCP 66, RFC 3406, October 2002. 320 Appendix A. Changes from RFC 2141 322 This document makes the following substantive changes from [RFC2141]: 324 o Disallowed "-" at the end of a NID. 325 o Allowed the "~" and "&" characters in an NSS. 326 o Formally registered 'urn' as a URI scheme. 328 Appendix B. Acknowledgements 330 RFC 2141, which provided the basis for this document, was authored by 331 Ryan Moats. 333 Thanks to Julian Reschke for his corrections to the ABNF. 335 Authors' Addresses 337 Peter Saint-Andre (editor) 338 Cisco Systems, Inc. 339 1899 Wynkoop Street, Suite 600 340 Denver, CO 80202 341 USA 343 Phone: +1-303-308-3282 344 Email: psaintan@cisco.com 346 Ryan Moats