idnits 2.17.1 draft-ietf-urnbis-semantics-clarif-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 updates RFC3986, but the abstract doesn't seem to directly say this. It does mention RFC3986 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 (Using the creation date from RFC3986, updated by this document, for RFC5378 checks: 2002-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2016) is 2993 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) == Unused Reference: 'DeterministicURI' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'URN-transition' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) -- Duplicate reference: RFC2141, mentioned in 'RFC2141bis', was also mentioned in 'RFC2141'. ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Uniform Resource Names (urnbis) J. Klensin 3 Internet-Draft February 5, 2016 4 Updates: 3986 (if approved) 5 Intended status: Standards Track 6 Expires: August 8, 2016 8 URN Semantics Clarification 9 draft-ietf-urnbis-semantics-clarif-03.txt 11 Abstract 13 Experience has shown that identifiers associated with persistent 14 names have properties and requirements that may be somewhat different 15 from identifiers associated with the locations of objects. This is 16 especially true when such names are expected to be stable for a very 17 long time or when they identify large and complex entities. In order 18 to allow Uniform Resource Names (URNs) to evolve to meet the needs of 19 the Library, Museum, Publisher, and Information Science communities 20 and other users, this specification separates URNs from the semantic 21 constraints that many people believe are part of the specification 22 for Uniform Resource Identifiers (URIs) in RFC 3986, updating that 23 document accordingly. The syntax of URNs is still constrained to 24 that of RFC 3986, so generic URI parsers are unaffected by this 25 change. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 8, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The role of queries and fragments in URNs . . . . . . . . . . 4 64 4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5 65 5. Actions Occurring in Parallel with this Specification . . . . 5 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Background on the URN - URI relationship . . . . . . 9 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 75 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 76 (2014-04-07) to -01 (2014-07-03) . . . . . . . . . . . . 9 77 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 78 to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 10 79 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 80 (2014-08-25) to -01 . . . . . . . . . . . . . . . . . . . 10 81 B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 82 (2015-02-14) to -02 . . . . . . . . . . . . . . . . . . . 11 83 B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 84 (2015-08-10) to -03 . . . . . . . . . . . . . . . . . . . 11 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 The Generic URI Syntax specification [RFC3986] covers both locators 90 and names and mixtures of the two (See its Section 1.1.3) and 91 describes Uniform Resource Locators (URLs) -- first documented in the 92 IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept 93 and Uniform Resource Names (URNs), specifically those using the "urn" 94 scheme [RFC2141], as an embodiment of the names that do not directly 95 provide for resource location. This specification is concerned only 96 about URNs of the variety described in RFC 2141 [RFC2141] and its 97 successors [RFC2141bis] (i.e., those that use the "urn" scheme). 98 URLs, other types of names, and any URI types that may not fall into 99 one of the above categories are out of its scope and unaffected by 100 it. 102 Experience with URNs since the publication of RFC 3986 has identified 103 several ways in which their inclusion under the 3986 scope has 104 hampered understanding, adoption, and especially extension 105 (specifically extensions of types that were anticipated, but not 106 defined, in RFC 2141). The need for extensions to the URN concept is 107 now being felt in some communities, especially those that include 108 libraries, museums, publishers, and other information scientists. 110 In particular, the Generic URI Syntax specification goes beyond 111 syntax to specify the meaning and interpretation of various fields, 112 especially the "query" and "fragment" ones and the various syntax 113 forms and interpretations it allows for . This 114 specification excludes URNs from those definitions of meaning and 115 interpretation so that RFC 3986 applies to their syntax only. The 116 meaning --and any more specific syntax rules-- for those fields for 117 URNs are now defined in a URN-specific document [RFC2141bis]. URNs 118 remain members of the URI family and parsers for generic URI syntax 119 are not affected by this specification although parsers that make 120 assumptions based on other URI schemes obviously might be. 122 Neither this specification nor the successor to RFC 2141 [RFC2141bis] 123 discusses DDDS [RFC3401] resolution or conversion to (and 124 interpretation of) URCs [RFC2483] or, with the exception of providing 125 some syntax to cover some specific cases, URN "resolution" more 126 generally. Any of those topics that do need to be addressed should 127 be covered in other documents. The document also does not discuss 128 alternatives to URNs, either those that might use a different scheme 129 name within the RFC 3986 URI framework or those that might use a 130 different framework entirely. In particular, some externally-defined 131 content or object identification systems could be represented either 132 by a URN namespace or through separate URI schemes. This 133 specification does not offer advice on that choice other than to 134 suggest that the two options not be confused (or both used in a way 135 that would be confusing). 137 This document updates RFC 3986 to make the distinction between syntax 138 and semantics clear for URNs and to isolate URNs from presumed URI 139 semantic requiremnts. It is important to note that some readers of 140 RFC 3986 are convinced that the separation is clear in that 141 specification and therefore that no changes to that document are 142 needed. For them, this specification is only a confirming 143 clarification. 145 In the long term, as the expanded syntax and uses of URNs become 146 commonplace and RFC 3986 is updated, this specification is likely to 147 become of historical interest only, providing an extended rationale 148 for decisions made and adjustment of the boundary between URN 149 specifications and generic URI ones. 151 2. Pragmatic Goals 153 Despite the important background and rationale in the sections that 154 follow, the change made (or clarification provided) by this 155 specification is driven by a desire to avoid philosophical debates 156 about terminology or ultimate truths. Instead, it is motivated by 157 three very pragmatic principles and goals: 159 1. Accommodate all of those who think URNs are necessary, i.e., that 160 they can and should be usefully distinguished from other URIs, at 161 least location-oriented ones including URI schemes defined prior 162 to the time work started on this document in August 2014. In 163 particular, provide a foundation for extensions to the URN syntax 164 (as allowed by and partially defined in RFC 2141) to support 165 requirements encountered by some of those communities. 167 2. Provide a path to avoid getting bogged down in declarative 168 statements about definitions and debates about what is and is not 169 correct in the abstract. 171 3. Avoid a fork in the standard that would be likely to lead to 172 multiple, conflicting, definitions or criteria for URNs. 174 In addition, this document is intended to move past debates about 175 whether or not URNs are intended to be parsed at all (i.e., whether a 176 "urn"-scheme URI is simply opaque to a URI parser once the scheme 177 name is identified) and, if not, how much of it is actually expected 178 to be understood and broken into identifiable parts by such a parser. 179 It establishes a principle that, for the "urn" scheme, parsing into 180 the components identified in RFC 3986 will be performed but that any 181 meanings or interpretation assigned to those components (including 182 that applicability of the normal English meanings of such terms as 183 "query" or "fragment" are a matter for URN-specific specifications. 184 It helps lay the foundation for the distinguishing terms 185 "q-component", "r-component", and "f-component" in the accompanying 186 URN definition specification [RFC2141bis]. 188 3. The role of queries and fragments in URNs 190 Part of the concern that led to this document was a desire to 191 accommodate URN components that would be analogous to the query and 192 fragment components of generalized URNs but that might have different 193 properties. For many cases, the analogy cannot be exact. For 194 example, RFC 3986 ties the interpretation of fragments to media 195 types. Since media type is a function of specific content, URNs that 196 are never resolved cannot have an associated media type, nor can URNs 197 that resolve to, for example, other URIs that may then not be 198 resolved further. Similarly, while the RFC 3986 syntax for queries 199 (and fragments) may be entirely appropriate for URN use, terminology 200 like "Service Request" (see Appendix B of the predecessor "URNs are 201 not..." draft [ServiceRequests] for additional discussion) may be 202 more suitable to the URN context than "query" (if, indeed, the 203 portion of the URN that is syntactically equivalent to a URI query is 204 where those requests belong). 206 4. Changes to RFC 3986 208 This specification removes URN semantics from the scope of RFC 3896. 209 It makes no changes to the generic URI syntax. That syntax still 210 applies to URNs as well as to other URI types. Even as regard to 211 semantics, it has no practical effect for URNs defined in strict 212 conformance to the prior URN specification [RFC2141] or the 213 associated registration specification [RFC3406]. 215 In particular (but without altering RFC 3986 in any way), the generic 216 URI syntax for "queries" (strings starting with "?" and continuing to 217 the end of the URI or to a "#"), and for "fragments" (strings 218 starting with "#" and continuing to the end of the URI) is unchanged. 219 For URNs, additional syntax is introduced to divide the URI "query" 220 into two parts, referred to as "q-components" and "r-components". 221 The syntax and general semantics of "fragments" (specified in RFC 222 3986 as scheme-independent) are unchanged, but a somewhat liberal 223 interpretation may be needed in the context of URNs, so a fragment is 224 referred to as an "f-component" as a term of convenience to highlight 225 that distinction. [RFC2141bis]. 227 5. Actions Occurring in Parallel with this Specification 229 The basic URN syntax specification [RFC2141] was published well 230 before RFC 3986 and therefore does not depend on it. The successor 231 to that specification [RFC2141bis], fully spells out, or references 232 documents that spell out, the semantics and any required within-field 233 syntax of URNs. It uses great care about generic or implicit 234 reference to any URI specification and delegates further details to 235 specific namespaces. 237 [[CREF1: Note in Draft: Perhaps this section can be dropped 238 entirely.]] 240 6. Acknowledgments 242 This specification was inspired by a search in the IETF URNBIS WG for 243 an approach that would both satisfy the needs of persistent name-type 244 identifiers and still fully conform to the specifications and intent 245 of RFC 3986. That search lasted several years and considered many 246 alternatives. Discussions with Leslie Daigle, Juha Hakala, Barry 247 Leiba, Keith Moore, Andrew Newton, and Peter Saint-Andre during the 248 last quarter of 2013 and the first quarter of 2014 were particularly 249 helpful in arriving at the conclusion that a conceptual separation of 250 notions of location-based identifiers (e.g., URLs) and the types of 251 persistent identifiers represented by URNs was necessary. Juha 252 Hakala provided useful explanations and significant working text 253 about the needs of the library community and their perception of 254 identifiers and consequent implications for URN structure. Peter 255 Saint-Andre provided significant text in a pre-publication review. 256 The author also appreciates the efforts of several people, notably 257 Tim Berners-Lee, Leslie Daigle, Larry Masinter, Keith Moore, Juha 258 Hakala, Julian Reschke, Lars Svensson, Henry S. Thompson, and Dale 259 Worely, to challenge text and ideas and demand answers to hard 260 questions. Whether they agree with the results or not, their 261 insights have contributed significantly to whatever clarity and 262 precision appears in the present document. 264 The specification was changed considerably and its focus narrowed 265 after an extended discussion at the WG meeting during IETF 90 in July 266 2014 [IETF90-URNBISWG] and subsequent comments and clarifications on 267 the mailing list [URNBIS-MailingList]. The contributions of all of 268 the participants in those discussions, only some of whose names 269 appear above, are gratefully acknowledged. 271 7. Contributors 273 Juha Hakala contributed considerable text, some of which was removed 274 from later versions of the document to streamline it. 276 Contact Information: 277 Juha Hakala 278 The National Library of Finland 279 P.O. Box 15, Helsinki University 280 Helsinki, MA FIN-00014 281 Finland 282 Email: juha.hakala@helsinki.fi 284 8. IANA Considerations 286 [[CREF2: RFC Editor: Please remove the first paragraph below before 287 publication.]] 289 This memo is not believed to require any action on IANA's part. 291 There is an existing (i.e. prior to the publication of this document) 292 registry for "Uniform Resource Identifier (URI) Schemes" that already 293 includes the "urn" scheme itself and a separate existing URN 294 Namespace registry. None of those registrations have any specific 295 dependencies on generic URI specifications. 297 9. Security Considerations 299 This specification changes the semantics of URNs to make them self- 300 contained (as specified in other documents), relying on the generic 301 URI syntax specification for syntax only. It should have no effect 302 on Internet security unless the use of a definition, syntax, and 303 semantics that are more clear reduces the potential for confusion and 304 consequent vulnerabilities. 306 10. References 308 10.1. Normative References 310 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 311 May 1997, . 313 [RFC2141bis] 314 Saint-Andre, P. and J. Klensin, "Uniform Resource Name 315 (URN) Syntax", February 2016, 316 . 319 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 320 Resource Identifier (URI): Generic Syntax", STD 66, 321 RFC 3986, DOI 10.17487/RFC3986, January 2005, 322 . 324 10.2. Informative References 326 [DeterministicURI] 327 Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic 328 URI Encoding", February 2014, . 331 This is an expired document, cited for historical context 332 only. 334 [IETF90-URNBISWG] 335 IETF, "URN BIS Working Group Minutes", July 2014, 336 . 339 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 340 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 341 December 1994, . 343 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 344 Necessary for URN Resolution", RFC 2483, 345 DOI 10.17487/RFC2483, January 1999, 346 . 348 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 349 Part One: The Comprehensive DDDS", RFC 3401, 350 DOI 10.17487/RFC3401, October 2002, 351 . 353 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 354 "Uniform Resource Names (URN) Namespace Definition 355 Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, 356 October 2002, . 358 [ServiceRequests] 359 Klensin, J., "Names are Not Locators and URNs are Not 360 URIs, Appendix B", July 2014, . 363 This is an expired document, cited for historical context 364 only. 366 [URN-transition] 367 Klensin, J. and J. Hakala, "Uniform Resource Name (URN) 368 Namespace Registration Transition", Feburary 2016, 369 . 372 [URNBIS-MailingList] 373 IETF, "IETF URN Mailing list", 2014, 374 . 376 Appendix A. Background on the URN - URI relationship 378 The Internet community now has many years of experience with both 379 name-type identifiers and location-based identifiers (or "references" 380 for those who are sensitive to the term "identifier" such as many 381 members of the library and information science communities.. The 382 primary examples of these two categories are Uniform Resource Names 383 (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) 384 [RFC1738]). That experience leads to the conclusion that it is 385 impractical to constrain URNs to the high-level semantics of URLs. 386 The generic syntax for URIs [RFC3986] is adequately flexible to 387 accommodate the perceived needs of URNs, but the specific semantics 388 associated with the URI syntax definition -- what particular 389 constructions "mean" and how and where they are interpreted -- appear 390 to not be. Generalization from URLs to generic Uniform Resource 391 Identifiers (URIs) [RFC3986], especially to name-based, high- 392 stability, long-persistence, identifiers such as many URNs, has 393 failed because the assumed similarities do not adequately extend to 394 all forms of URNs. Ultimately, locators, which typically depend on 395 particular accessing protocols and a specification relative to some 396 physical space or network topology, are simply different creatures 397 from long-persistence, location-independent, object identifiers. The 398 syntax and semantic constraints that are appropriate for locators are 399 either irrelevant to or interfere with the needs of resource names as 400 a class. That was tolerable as long as the URN system didn't need 401 additional capabilities (over those specified in RFC 2141) but 402 experience since RFC 2141 was published has shown that they are, in 403 fact, needed. 405 Appendix B. Change Log 407 [[CREF3: RFC Editor: Please remove this appendix before 408 publication.]] 410 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 (2014-04-07) 411 to -01 (2014-07-03) 413 o Revised Section 1 slightly and added some new material to try to 414 address questions raised on the mailing list. 416 o Added Section 2, reflecting an email exchange. 418 o Added a Security Considerations section, replacing the placeholder 419 in the previous version. 421 o Added later-deleted Appendix B and inserted a note in the material 422 titled "A Perspective on Locations and Names" pointing to it (that 423 material was removed from draft-ietf-urnbis-semantics-clarif-01, 424 but was Section 2 and then Section 3 in earlier versions). 426 o Added temporary Appendix B for this version only. 428 o Enhanced and updated the Acknowledgments section. 430 o The usual small clarifications and editorial changes. 432 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 to draft-ietf- 433 urnbis-semantics-clarif-00 (2014-08-25) 435 o Changed title and file name to better reflect changes summarized 436 below. Note that the predecessor of this document was draft-ietf- 437 urnbis-urns-are-not-uris-01. 439 o Revised considerably as discussed on the mailing list and at IETF 440 90. In particular, the document has been narrowed to change 441 semantics only without affecting the relationship to URI syntax 442 and the document title and other details changed to match. 444 o Dropped much of the original Introduction (moving it temporarily 445 to an appendix) and trimmed the abstract to be consistent with the 446 new, more limited. scope. 448 o Revised an earlier version of Appendix B to make "perceived 449 requirement" more clear. 451 o Removed the former Appendix B, as promised in the previous draft, 452 moved considerably more text into appendices, and added some new 453 appendix text. 455 o Added new material to discuss the next round of decisions the WG 456 will have to make, assuming this provisions of this specification 457 are approved. That material was removed from draft-ietf-urnbis- 458 semantics-clarif-01. 460 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) to 461 -01 463 o Removed some appendices and the topic discussion material, as 464 discused in the previous draft. 466 o Aligned the document and its terminology somewhat better with 467 draft-ietf-urnbis-rfc2141bis-urn-09 including providing for 468 p-components and using the p-/q-/f-component terminology. 470 o Made several clarifying changes to reflect mailing list 471 discussions (mostly of 2141bis) since the earlier version was 472 posted. 474 o Revised earlier portions of this change tracking appendix to 475 remove referenced to deleted material. It is not possible to 476 reconstruct what earlier versions of this document contained by 477 examining these change summaries. 479 o Moved specific comments about the IETF 90 discussions to 480 Acknowledgments and removed or edited some material that was only 481 appropriate for a discussion piece. 483 o Made several small editorial changes as usual. 485 B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 (2015-02-14) to 486 -02 488 o Reissued to keep draft alive; no substantive changes. 490 o Updated references, including some that were already outdated in 491 -01. 493 B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 (2015-08-10) to 494 -03 496 o Made a few substantive updates to reflect evolution in 2141bis, 497 particularly the elimination of p-component as a separate category 498 and the added distinction between q-component and r-component.. 500 o Updated references and made several minor editorial changes to 501 improve clarity. 503 Author's Address 505 John C Klensin 506 1770 Massachusetts Ave, Ste 322 507 Cambridge, MA 02140 508 USA 510 Phone: +1 617 245 1457 511 Email: john-ietf@jck.com