idnits 2.17.1 draft-ietf-urnbis-semantics-clarif-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 : ---------------------------------------------------------------------------- -- 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 (June 8, 2016) is 2872 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) == Missing Reference: 'ThisRFC' is mentioned on line 263, but not defined == Unused Reference: 'DeterministicURI' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'URN-transition' is defined on line 459, 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 (~~), 4 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 June 8, 2016 4 Updates: 3986 (if approved) 5 Intended status: Standards Track 6 Expires: December 10, 2016 8 URN Semantics Clarification 9 draft-ietf-urnbis-semantics-clarif-04 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 Advice to RFC Editor and WG 29 Note to RFC Editor: Various comments in drafts of this documents were 30 written to describe the situation in, and perspective of, the WG. 31 They will need careful checking for tense if the document is queued 32 for publication as an RFC. 33 WG participants: please do not spend time reporting or discussing 34 that type of obvious editorial issues or, e.g., the amount of white 35 space after periods -- the RFC Production Center are really very good 36 at their jobs. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 10, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. The role of queries and fragments in URNs . . . . . . . . . . 5 75 4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 6 76 5. Actions Occurring in Parallel with this Specification . . . . 7 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 10.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Appendix A. Background on the URN - URI relationship . . . . . . 10 85 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 86 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 87 (2014-04-07) to -01 (2014-07-03) . . . . . . . . . . . . 11 88 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 89 to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 12 90 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 91 (2014-08-25) to -01 . . . . . . . . . . . . . . . . . . . 12 92 B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 93 (2015-02-14) to -02 . . . . . . . . . . . . . . . . . . . 13 94 B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 95 (2015-08-10) to -03 . . . . . . . . . . . . . . . . . . . 13 97 B.6. Changes from draft-ietf-urnbis-semantics-clarif-03 98 (2016-02-07) to -04 . . . . . . . . . . . . . . . . . . . 13 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 The Generic URI Syntax specification [RFC3986] covers both locators 104 and names and mixtures of the two (See its Section 1.1.3) and 105 describes Uniform Resource Locators (URLs) -- first documented in the 106 IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept 107 and Uniform Resource Names (URNs), specifically those using the "urn" 108 scheme [RFC2141], as an embodiment of the names that do not directly 109 provide for resource location. This specification is concerned only 110 about URNs of the variety described in RFC 2141 [RFC2141] and its 111 successors [RFC2141bis] (i.e., those that use the "urn" scheme). 112 URLs, other types of names, and any URI types that may not fall into 113 one of the above categories are out of its scope and unaffected by 114 it. 116 Experience with URNs since the publication of RFC 3986 has identified 117 several ways in which their inclusion under the 3986 scope has 118 hampered understanding, adoption, and especially extension 119 (specifically types of extensions that were anticipated, but not 120 defined, in RFC 2141). The need for extensions to the URN concept is 121 now being felt in some communities, especially those that include 122 libraries, museums, publishers, and other information scientists. 124 In particular, the Generic URI Syntax specification goes beyond 125 syntax to specify the meaning and interpretation of various fields, 126 especially the "query" and "fragment" ones and the various syntax 127 forms and interpretations it allows for . There is 128 disagreement in the community about whether some of the statements in 129 RFC 3986 are normative requirements or discussion of possible options 130 and, if the latter, whether the options given are an exclusive list. 131 Sequences of statements in that document that can be read in 132 different ways reinforce those disagreements. As one example, the 133 3986 discussion of fragments (see Section 3.5, especially the first 134 two paragraphs) has been read as leaving the interpretation of 135 strings in fragment syntax that are not associated with retrievable 136 objects and media types as undefined and unconstrained and hence 137 available for other uses. Others have read the second paragraph as 138 prohibiting any interpretation or use of fragments on a per-scheme 139 basis, essentially prohibiting them when the URI does not resolve to 140 an object with a media type. 142 This document does not attempt to resolve those disagreements. Doing 143 so does not seem to be necessary and would be far out of scope for 144 the WG that produced it, and would mire URN work in controversies 145 that might never be resolved. Instead, it provides what might best 146 be thought of as an interpretation rule: if someone reads a statement 147 about the meaning or interpretation of a particular field, or non- 148 syntactic restrictions on it, as inconsistent between RFC 3986 and 149 this document and/or [RFC2141bis], these URN-specific documents 150 prevail (again, only for the "urn:" scheme; any extension to other 151 types of names would be the subject of other work). 153 In other words, this specification excludes URNs from the RFC 3986 154 definitions of meaning and interpretation so that RFC 3986 applies, 155 for URNs, to their syntax only. The meaning --and any more specific 156 syntax rules-- for those fields for URNs are now defined in a URN- 157 specific document [RFC2141bis]. URNs remain members of the URI 158 family and parsers for generic URI syntax are not affected by this 159 specification although parsers that make assumptions based on other 160 URI schemes obviously might be. 162 Neither this specification nor the successor to RFC 2141 [RFC2141bis] 163 discusses DDDS [RFC3401] resolution or conversion to (and 164 interpretation of) URCs [RFC2483] or, with the exception of providing 165 some syntax to cover some specific cases, URN "resolution" more 166 generally. Any of those topics that do need to be addressed should 167 be covered in other documents. The document also does not discuss 168 alternatives to URNs, either those that might use a different scheme 169 name within the RFC 3986 URI framework or those that might use a 170 different framework entirely. In particular, some externally-defined 171 content or object identification systems could be represented either 172 by a URN namespace or through separate URI schemes. This 173 specification does not offer advice on that choice other than to 174 suggest that the two options not be confused (or both used in a way 175 that would be confusing). 177 In the long term, as the expanded syntax and uses of URNs become 178 commonplace and RFC 3986 is updated, this specification is likely to 179 become of historical interest only, providing an extended rationale 180 for decisions made and adjustment of the boundary between URN 181 specifications and generic URI ones, especially those that are used 182 as locators rather than names. 184 2. Pragmatic Goals 186 Despite the important background and rationale in other sections of 187 this document, the change made (or clarification provided) by this 188 specification is driven by a desire to avoid philosophical debates 189 about terminology, ultimate truths, or even different interpretations 190 of RFC 3986. Instead, it is motivated by three very pragmatic 191 principles and goals: 193 1. Accommodate the communities who think URNs are necessary, i.e., 194 that they can and should be usefully distinguished from other 195 URIs, at least location-oriented ones (including URI schemes 196 defined prior to the time work started on this document in August 197 2014). In particular, provide a foundation for extensions to the 198 URN syntax (as allowed by and partially defined in RFC 2141) to 199 support requirements encountered by some of those communities. 201 2. Provide a path to avoid getting bogged down in declarative 202 statements about definitions and debates about what is and is not 203 abstractly correct. 205 3. Avoid a fork in the standard that would be likely to lead to 206 multiple, conflicting, definitions or criteria for URNs. 208 In addition, this document is intended to move past debates about 209 whether or not URNs are intended to be parsed at all (i.e., whether a 210 "urn"-scheme URI is simply opaque to a URI parser once the scheme 211 name is identified) and, if not, how much of it is actually expected 212 to be understood and broken into identifiable parts by such a parser. 213 It establishes a principle that, for the "urn" scheme, parsing into 214 the components identified in RFC 3986 may be performed but that any 215 meanings or interpretation assigned to those components (including 216 application of the normal English meanings of such terms as "query" 217 or "fragment") are a matter for URN-specific specifications. That 218 principle and its application provides a foundation for the 219 distinguishing terms "q-component", "r-component", and "f-component" 220 that are developed in the accompanying URN definition specification 221 [RFC2141bis]. 223 3. The role of queries and fragments in URNs 225 [[CREF1: Note in Draft to WG: Given what is now above and material in 226 2141bis, I suggest removing this section entirely (if needed, 227 transposing it into 2141bis). If we do retain it, it almost 228 certainly needs more work. Comments, specifically about whether it 229 should be removed and, if so, what changes (if any) are needed to 230 2141bis, would be appreciated. --JcK (-04) ]] 232 Part of the concern that led to this document was a desire to 233 accommodate URN components that would be analogous to the query and 234 fragment components of generalized URNs but that might have different 235 properties. For many cases, the analogy cannot be exact. For 236 example, RFC 3986 ties the interpretation of fragments to media 237 types. Since media type is a function of specific content, URNs that 238 are never resolved cannot have an associated media type, nor can URNs 239 that resolve to, for example, other URIs that may then not be 240 resolved further. Similarly, while the RFC 3986 syntax for queries 241 (and fragments) may be entirely appropriate for URN use, terminology 242 like "Service Request" (see Appendix B of the predecessor "URNs are 243 not..." draft [ServiceRequests] for additional discussion) may be 244 more suitable to the URN context than "query" (if, indeed, the 245 portion of the URN that is syntactically equivalent to a URI query is 246 where those requests belong). 248 4. Changes to RFC 3986 250 The interpretation rule discussed in Section 1 notwithstanding, this 251 document alters ("updates") RFC 3986 itself only by specifying that 252 the interpretation of URNs of the "urn:" scheme, may vary from that 253 for other types of URIs. That might be implemented by, for example, 254 inserting text at the end of Section 1.1.3 (of RFC 3986) similar to: 256 Nonetheless, URIs classified as names, particularly those of the 257 "urn:" scheme, may require different interpretations of, or even 258 deviations from, the interpretations of various fields or rules of 259 this document that are more obviously applicable to locators. 260 Those differences are motivated by differences in the 261 relationships to retrievable objects and other resources between 262 locators and more abstract names. For the "urn:" scheme, the 263 issues are discussed in [ThisRFC] and specific definitions are 264 supplied in [RFC2141bis]. 266 [[CREF2: Note in Draft: The above example suggested text opens the 267 door to unbinding _all_ name-type URIs from the semantics of 3986 268 despite assertions elsewhere in this document that anything other 269 then the "urn:" scheme is out of scope. In reviewing 3986, the 270 example location and text seemed the best and most consistent way to 271 modify the relevant section. That section definitely does not talk 272 about individual schemes. WG participants, in reviewing this section 273 and text, should note that IETF procedures have never required that a 274 specification that "updates" a document provide modifying text nor 275 that an author or WG working on a revision to the document thereby 276 updated use that text. I've included it here because of discussion 277 on the mailing list to the effect that this document was unclear 278 about just how it updated 3986 -- the above is intended to make that 279 crystal-clear. Alternate text that would not have those issues would 280 be welcome. --JcK (-04)]] 282 The effect of the above is to remove URN semantics from the scope of 283 RFC 3986. It makes no changes to the generic URI syntax, nor to the 284 semantics of any other URI scheme. The 3986 syntax still applies to 285 URNs as well as to other URI types. Even as regard to semantics, it 286 has no practical effect for URNs defined in strict conformance to the 287 prior URN specification [RFC2141] or the associated registration 288 specification [RFC3406]. 290 [[CREF3: I think the paragraph that follows can safely be dropped and 291 will do so in future versions (if any) unless there are comments to 292 the contrary that explain what purpose it serves and any needed 293 changes. --JcK (-04)]] 295 In particular (but without altering RFC 3986 in any way), the generic 296 URI syntax for "queries" (strings starting with "?" and continuing to 297 the end of the URI or to a "#"), and for "fragments" (strings 298 starting with "#" and continuing to the end of the URI) is unchanged. 299 For URNs, additional syntax is introduced to divide the URI "query" 300 into two parts, referred to as "q-components" and "r-components". 301 The syntax and general semantics of "fragments" (specified in RFC 302 3986 as scheme-independent) are unchanged, but a somewhat liberal 303 interpretation may be needed in the context of URNs, so a fragment is 304 referred to as an "f-component" as a term of convenience to highlight 305 that distinction [RFC2141bis]. 307 5. Actions Occurring in Parallel with this Specification 309 The basic URN syntax specification [RFC2141] was published well 310 before RFC 3986 and therefore does not depend on it. The successor 311 to that specification [RFC2141bis], fully spells out, or references 312 documents that spell out, the semantics and any required within-field 313 syntax of URNs. It uses great care about generic or implicit 314 reference to any URI specification and delegates further details to 315 specific namespaces. 317 [[CREF4: Note in Draft: Perhaps this section can be dropped entirely. 318 --JcK (04)]] 320 6. Acknowledgments 322 This specification was inspired by a search in the IETF URNBIS WG for 323 an approach that would both satisfy the needs of persistent name-type 324 identifiers and still fully conform to various readings and 325 understandings of the specifications and intent of RFC 3986. That 326 search lasted several years and considered many alternatives. 327 Discussions with Leslie Daigle, Juha Hakala, Barry Leiba, Keith 328 Moore, Andrew Newton, and Peter Saint-Andre during the last quarter 329 of 2013 and the first quarter of 2014 were particularly helpful in 330 arriving at the conclusion that a conceptual separation of notions of 331 location-based identifiers (e.g., URLs) and the types of persistent 332 identifiers represented by URNs was necessary. Juha Hakala provided 333 useful explanations and significant working text about the needs of 334 the library community and their perception of identifiers and 335 consequent implications for URN structure. Peter Saint-Andre 336 provided significant text in a pre-publication review. The author 337 also appreciates the efforts of several people, notably Tim Berners- 338 Lee, Leslie Daigle, Juha Hakala, Sean Leonard, Larry Masinter, Keith 339 Moore, Julian Reschke, Lars Svensson, Henry S. Thompson, and Dale 340 Worely, to challenge text and ideas and demand answers to hard 341 questions. Whether they agree with the results or not, their 342 insights have contributed significantly to whatever clarity and 343 precision appears in the present document. 345 The specification was changed considerably and its focus narrowed 346 after an extended discussion at the WG meeting during IETF 90 in July 347 2014 [IETF90-URNBISWG] and subsequent comments and clarifications on 348 the mailing list [URNBIS-MailingList]. The contributions of all of 349 the participants in those discussions, only some of whose names 350 appear above, are gratefully acknowledged. 352 7. Contributors 354 Juha Hakala contributed considerable text, some of which was removed 355 from later versions of the document to streamline it. 357 Contact Information: 358 Juha Hakala 359 The National Library of Finland 360 P.O. Box 15, Helsinki University 361 Helsinki, MA FIN-00014 362 Finland 363 Email: juha.hakala@helsinki.fi 365 8. IANA Considerations 367 [[CREF5: RFC Editor: Please remove the first paragraph below before 368 publication.]] 370 This memo is not believed to require any action on IANA's part. 372 There is an existing (i.e. prior to the publication of this document) 373 registry for "Uniform Resource Identifier (URI) Schemes" that already 374 includes the "urn" scheme itself and a separate existing URN 375 Namespace registry. None of the registrations that predate this 376 specification have any specific dependencies on generic URI 377 specifications. More information on this subject appears in 378 [RFC2141bis] and documents referenced from it. 380 9. Security Considerations 382 As discussed in Section 1 above, this document is largely 383 precautionary, providing an interpretation rule for the URI 384 definition [RFC3986] when URNs are concerned. Some members of the 385 community believe that rule (and hence this document) are 386 unnecessary, at most reinforcing provisions already in that 387 definition. Others believe that it restores the original URN 388 definition [RFC2141], produced before RFC 3986 was adopted and not 389 updated by it. Still others see this specification as making a 390 necessary change to allow the semantics of URNs to be self-contained 391 (as specified in other documents), relying on the generic URI syntax 392 specification for syntax only. 394 Independent of which of those models is applicable, the specification 395 should have no effect on Internet security unless the use of a 396 definition, syntax, and semantics that are more clear reduces the 397 potential for confusion and consequent vulnerabilities. 399 10. References 401 10.1. Normative References 403 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 404 May 1997, . 406 [RFC2141bis] 407 Saint-Andre, P. and J. Klensin, "Uniform Resource Name 408 (URN) Syntax", February 2016, 409 . 412 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 413 Resource Identifier (URI): Generic Syntax", STD 66, 414 RFC 3986, DOI 10.17487/RFC3986, January 2005, 415 . 417 10.2. Informative References 419 [DeterministicURI] 420 Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic 421 URI Encoding", February 2014, . 424 This is an expired document, cited for historical context 425 only. 427 [IETF90-URNBISWG] 428 IETF, "URN BIS Working Group Minutes", July 2014, 429 . 432 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 433 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 434 December 1994, . 436 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 437 Necessary for URN Resolution", RFC 2483, 438 DOI 10.17487/RFC2483, January 1999, 439 . 441 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 442 Part One: The Comprehensive DDDS", RFC 3401, 443 DOI 10.17487/RFC3401, October 2002, 444 . 446 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 447 "Uniform Resource Names (URN) Namespace Definition 448 Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, 449 October 2002, . 451 [ServiceRequests] 452 Klensin, J., "Names are Not Locators and URNs are Not 453 URIs, Appendix B", July 2014, . 456 This is an expired document, cited for historical context 457 only. 459 [URN-transition] 460 Klensin, J. and J. Hakala, "Uniform Resource Name (URN) 461 Namespace Registration Transition", Feburary 2016, 462 . 465 [URNBIS-MailingList] 466 IETF, "IETF URN Mailing list", 2014, 467 . 469 Appendix A. Background on the URN - URI relationship 471 [[CREF6: Note in Draft: I've slightly rewritten this Appendix, but 472 suspect it may still be controversial. If it is, the WG should 473 discuss whether the advantages of having the explanation justify the 474 energy to figure out exactly what it should say or whether those 475 advantages are few enough that it should just be dropped. --JcK 476 (-04).]] 477 The Internet community now has many years of experience with both 478 name-type identifiers and location-based identifiers (or "references" 479 for those who are sensitive to the term "identifier" (a group that 480 includes many members of the library and information science 481 communities. The primary examples of these two categories are 482 Uniform Resource Names (URNs [RFC2141] [RFC2141bis]) and Uniform 483 Resource Locators (URLs) [RFC1738]). That experience leads to the 484 conclusion that it is impractical to constrain URNs to the high-level 485 semantics of URLs. The generic syntax for URIs [RFC3986] is 486 adequately flexible to accommodate the perceived needs of URNs, but 487 the specific semantics associated with the URI syntax definition -- 488 what particular constructions "mean" and how and where they are 489 constrained or interpreted -- appear to not be. Generalization from 490 URLs to generic Uniform Resource Identifiers (URIs) [RFC3986], 491 especially to name-based, high-stability, long-persistence, 492 identifiers such as many URN namespaces, has failed because the 493 assumed similarities do not adequately extend to all forms of, and 494 requirements for, URNs. 496 Ultimately, locators, which typically depend on particular accessing 497 protocols (protocols that are typically linked to the particular URI 498 scheme) and a specification relative to some physical space or 499 network topology, are simply different creatures from long- 500 persistence, location-independent, object identifiers or abstract 501 designators. Many of the constraints and interpretation rules that 502 are appropriate for locators are either irrelevant to or interfere 503 with the needs of resource names (at least of the "urn:" scheme) as a 504 class. That was tolerable as long as the URN system didn't need 505 additional capabilities (over those specified in RFC 2141) but 506 experience since RFC 2141 was published has shown that they are, in 507 fact, needed. 509 Appendix B. Change Log 511 [[CREF7: RFC Editor: Please remove this appendix before 512 publication.]] 514 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 (2014-04-07) 515 to -01 (2014-07-03) 517 o Revised Section 1 slightly and added some new material to try to 518 address questions raised on the mailing list. 520 o Added Section 2, reflecting an email exchange. 522 o Added a Security Considerations section, replacing the placeholder 523 in the previous version. 525 o Added later-deleted Appendix B and inserted a note in the material 526 titled "A Perspective on Locations and Names" pointing to it (that 527 material was removed from draft-ietf-urnbis-semantics-clarif-01, 528 but was Section 2 and then Section 3 in earlier versions). 530 o Added temporary Appendix B for this version only. 532 o Enhanced and updated the Acknowledgments section. 534 o The usual small clarifications and editorial changes. 536 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 to draft-ietf- 537 urnbis-semantics-clarif-00 (2014-08-25) 539 o Changed title and file name to better reflect changes summarized 540 below. Note that the predecessor of this document was draft-ietf- 541 urnbis-urns-are-not-uris-01. 543 o Revised considerably as discussed on the mailing list and at IETF 544 90. In particular, the document has been narrowed to change 545 semantics only without affecting the relationship to URI syntax 546 and the document title and other details changed to match. 548 o Dropped much of the original Introduction (moving it temporarily 549 to an appendix) and trimmed the abstract to be consistent with the 550 new, more limited. scope. 552 o Revised an earlier version of Appendix B to make "perceived 553 requirement" more clear. 555 o Removed the former Appendix B, as promised in the previous draft, 556 moved considerably more text into appendices, and added some new 557 appendix text. 559 o Added new material to discuss the next round of decisions the WG 560 will have to make, assuming this provisions of this specification 561 are approved. That material was removed from draft-ietf-urnbis- 562 semantics-clarif-01. 564 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) to 565 -01 567 o Removed some appendices and the topic discussion material, as 568 discussed in the previous draft. 570 o Aligned the document and its terminology somewhat better with 571 draft-ietf-urnbis-rfc2141bis-urn-09 including providing for 572 p-components and using the p-/q-/f-component terminology. 574 o Made several clarifying changes to reflect mailing list 575 discussions (mostly of 2141bis) since the earlier version was 576 posted. 578 o Revised earlier portions of this change tracking appendix to 579 remove referenced to deleted material. It is not possible to 580 reconstruct what earlier versions of this document contained by 581 examining these change summaries. 583 o Moved specific comments about the IETF 90 discussions to 584 Acknowledgments and removed or edited some material that was only 585 appropriate for a discussion piece. 587 o Made several small editorial changes as usual. 589 B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 (2015-02-14) to 590 -02 592 o Reissued to keep draft alive; no substantive changes. 594 o Updated references, including some that were already outdated in 595 -01. 597 B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 (2015-08-10) to 598 -03 600 o Made a few substantive updates to reflect evolution in 2141bis, 601 particularly the elimination of p-component as a separate category 602 and the added distinction between q-component and r-component. 604 o Updated references and made several minor editorial changes to 605 improve clarity. 607 B.6. Changes from draft-ietf-urnbis-semantics-clarif-03 (2016-02-07) to 608 -04 610 o Rewrote parts of Sections 1, 2, 9, and Appendix A to try to 611 clarify the intentions of this document and its relationship to 612 others, including better specifying and providing example location 613 and text for the "updates" relationship to RFC 3986. 615 o Added temporary editor's notes, marked "[[CREF ... -JcK (-04)", 616 the latter denoting the version, about issues the WG should 617 consider. 619 o Updated the Acknowledgments. 621 o Many small editorial corrections 623 Author's Address 625 John C Klensin 626 1770 Massachusetts Ave, Ste 322 627 Cambridge, MA 02140 628 USA 630 Phone: +1 617 245 1457 631 Email: john-ietf@jck.com