idnits 2.17.1 draft-masinter-dated-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 332: '...far in the past) SHOULD NOT be used, b...' RFC 2119 keyword, line 337: '...ractices are NOT RECOMMENDED, there is...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 1, 2002) is 8060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2550 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Masinter 3 Internet-Draft Adobe Systems Incorporated 4 Expires: September 30, 2002 April 1, 2002 6 "duri" and "tdb" URN namespaces based on dated URIs 7 draft-masinter-dated-uri-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 30, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document defines two namespaces of URNs based on prepending a 39 date to an (encoded) URI. The results are namespaces in which names 40 are readily assigned, offer the persistence of reference that is 41 required by URNs, but do not require a stable authority to assign the 42 name. The first namespace ("duri") is used to refer to URI- 43 identified resources as they appeared at a particular time. The 44 second namespace ("tdb") is useful as a way of creating URNs that 45 refer to abstractions that may not themselves be networked resources. 47 The definition of these namespaces may reduce the need to define new 48 URN namespaces merely for the purpose of creating stable identifiers. 50 Note 52 This document is not a product of any working group. Many of the 53 ideas here have been discussed for a number of years. This document 54 has been discussed on the mailing list . 56 1. Overview and Requirements 58 The URN namespaces defined here solve several related problems. 60 1.1 Easy URN assignment 62 The URN specification [3] allows for many URN namespaces, and many 63 have been registered. However, obtaining an appropriate URN in any 64 of the currently defined URN namespaces may be difficult: a number of 65 URN namespace registrations have been accompanied by comments that no 66 other URN namespace was available for the class of documents for 67 which identifiers were wanted. 69 1.2 Persistent identifiers 71 RFC 1737 [3] defines several requirements for Uniform Resource Names. 72 In particular, it requires "persistence": 74 Persistence: It is intended that the lifetime of a URN be 75 permanent. That is, the URN will be globally unique forever, and 76 may well be used as a reference to a resource well beyond the 77 lifetime of the resource it identifies or of any naming authority 78 involved in the assignment of its name. 80 Many people have wondered how to create globally unique and 81 persistent identifiers. There are a number of URI schemes and URN 82 namespaces already registered. However, an absolute guarantee of 83 both uniqueness and persistence is very difficult. 85 In some cases, the guarantee of persistence comes through a promise 86 of good management practice, such as is encouraged in "Cool URLs 87 don't change" [2]. However, relying on promise of good management 88 practice is not the same as having a design that guarantees 89 reliability independent of actual administrative practice. 91 A primary design goal for URIs is that they are intended to mean the 92 same thing, no matter in what context they appear: a "Uniform" way to 93 Identify a Resource. However, even when URIs have Uniform meaning 94 from the point of view of the source of the reference, they don't 95 guarantee stability over time. Despite best efforts and intentions, 96 identifying information can change in unpredictable ways: domain 97 names can disappear or be reassigned, name assigning organizations 98 can change structure, responsibility, disappear, merge, or change in 99 unpredictable ways. 101 There is a significant dependence in the interpretation of many URNs 102 with the concept of "naming authority". The authority is presumably 103 some individual or organization both to insure uniqueness of 104 assignment and also to help with understanding the meaning of the 105 link between the name and the named. 107 However, authorities, whether individuals or organizations, have a 108 lifetime, and must be consulted at some point to understand the 109 bindings. The functioning of names as unique identifiers and holders 110 of meaning depends on having a reliable infrastructure of consulting 111 the authority or the authorities records to determine the thing 112 referenced. 114 1.3 URIs for abstractions 116 The description of URIs [6] describes a range for 'Resource' that is 117 quite broad: 119 A resource can be anything that has identity. Familiar examples 120 include an electronic document, an image, a service (e.g., 121 "today's weather report for Los Angeles"), and a collection of 122 other resources. Not all resources are network "retrievable"; 123 e.g., human beings, corporations, and bound books in a library can 124 also be considered resources. 126 However, most of the URI mechanisms are either quite concrete, 127 (including an identification of protocol and protocol parameters for 128 connecting to a network communication endpoint), or else quite vague 129 about the way in which they are connected to the resource they 130 identify. There are no current URN namespaces (or URI schemes) that 131 allow easy assignment of URIs for abstractions. 133 The goal, then, of the second URN scheme proposed below is to provide 134 a mechanism which is, at the same time: 136 permanent: The identity of the resource identified is not subject 137 to reinterpretation over time. 139 explicitly bound: The mechanism by which the identified resource 140 can be determined is explicitly included in the URI. 142 useful for non-networked items: Allows identification of resources 143 outside the network: people, organizations, abstract concepts. 145 no administration: The mechanism does not depend on reliable 146 administrative processes of authorities for either assignment or 147 interpretation. 149 2. Namespace definitions 151 2.1 "duri" namespace 153 It is traditional in convention references and citations in printed 154 works to include the date of publication; this practice serves the 155 important purpose that the context of the naming can be determined. 157 The "duri" URN namespace takes the form: 158 urn:duri:: 160 where is a digit string corresponding to a date (Section 4), 161 and an is an absolute URI-reference [6] in which any 162 character excluded from URN syntax has been escaped (Section 3). 164 The meaning of a duri is "the resource (or fragment) that was 165 identified by the (after hex decoding) at the very 166 first instant of the date(time) given". 168 For example, 'urn:duri:2001:http://www.ietf.org' is a persistent 169 identifier to 'http://www.ietf.org' as of the very first moment of 170 the year 2001. A duri may not be a resource locator in a practical 171 sense, because the time of location has passed. However, is an 172 acceptable resource identifier, and fulfills all of the requirements 173 for URNs [3]. 175 2.2 "tdb" namespace 177 The second URN namespace defined is a parallel space which is useful 178 for describing entities, concepts, abstractions, and other items 179 which are not themselves network accessible resources, but have been 180 at some point described by network accessible resources. 182 The "tdb" namespace designates the "thing described by" a resource at 183 a given URI at the given time. This URN namespace is described by 184 'tdb', e.g., 186 urn:tdb:: 188 with the same syntactic rules as 'duri'. 190 The intent is to use the inversion of "is a document about". It is 191 common practice to give a reference for a concept by including a 192 pointer to a document, segment, phrase that defines the concept. 193 "tdb" attempts to capture this practice in URI space. 195 For example, "urn:tdb:2001:http://www.ietf.org" can be used to 196 designate the Internet Engineering Task Force organization, at least 197 as it was described by or referenced by its home page at the first 198 instant of 2001. 200 The "tdb" namespace differs from most other mechanisms for 201 identifying abstractions because the designation of what is actually 202 identified by the tdb doesn't depend on knowing the intention of the 203 "assigner" of the identifier. Unlike many of the alternatives 204 proposed, the identification is not dependent on the context of use. 206 The "tdb" namespace can be thought of as following another level of 207 indirection to URI resolution. While one could imagine using 'tdb' 208 without a date, it would leave the possibility that a reference that 209 is unambiguous at one time might become ambiguous at some other time. 211 3. Encoding URIs 213 Both "duri" and "tdb" URN namespaces require that some characters in 214 the URI references be encoded. 216 3.1 Characters that must be encoded 218 The characters that must be encoded are: 220 o All characters marked excluded in RFC 2141 [1], section 2.4 221 These are excluded because they are not allowed in URNs. 223 \"&<>[]^`{|}~ 225 o The character "#" 226 Note that the of a "duri" or "tdb" can include a 227 fragment identifier, but the "#" character used to delimit it must 228 be encoded. 230 o The character "%" 231 The encoded-URI can itself contain encoded characters, which are 232 encoded with the same method. To insure that decoding happens at 233 the right level of processing, the "%" itself must be encoded. 235 Unfortunately, there are many cases where there is a double encoding 236 of characters, first to construct the embedded URI itself and second 237 to then embed the URI within the tdb or duri URN. 239 3.2 Hierarchy and unencoded / 241 The URN specification [3] discourages the use of "/" in URNs because, 242 in general, there is no good interpretation of hierarchy and relative 243 URIs for assigned names. However, for the particular case of duris 244 (at least), there seems to be no good reason to avoid the "/" because 245 it corresponds fairly naturally (in many cases) to the hierarchy of 246 the original space. 248 Note that because of this, "duri" URNs can actually be used with 249 relative URI references with some amount of reliability. (The double 250 encoding of previously encoded URI characters causes some problems.) 252 4. Dates 254 A is a simple expression of date, optional time, with 255 arbitrary precision. The goal is to allow relatively short 256 expressions of dates with no ambiguity, and with arbitrary precision. 257 (The idea for this syntax came from [4].) 259 date = year [ month [ day [ hour [ minute [ second [ fraction ]]]]]] 261 year = 4digit 262 month = 2digit 263 day = 2digit 264 hour = 2digit 265 minute = 2digit 266 second = 2digit 267 fraction = *digit 269 The representation of a date or time refers to the very first instant 270 of the given date, so that, for example, 1999 and 199901010000 are 271 equivalent. If necessary, dates can include times and even 272 fractional times, so that a generator of duris can be arbitrarily 273 precise. 275 Dates are interpreted relative to International Atomic Time [7], so 276 that there is no ambiguity about time zone. 278 5. Additional Considerations 280 5.1 Embedded URI schemes 282 The intent of "duri" and "tdb" is to use them with embedded URI 283 references that identify documents or document fragments. 285 For example, use with a "http" URI can be used to refer to a web page 286 or the subject of a web site at a given time. This can be a way of 287 referring to a web site at some date in the past, or an organization 288 that has changed or merged. 290 Local systems that have unique host names can use "file" URIs with 291 "tdb", for example, 293 urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt 295 since this use is primarily focused on providing a unique way of 296 identifying an abstraction, even if the referent of the abstraction 297 is broadly known. (Using 'file:' URIs without a host name is not 298 recommended, because the interpretation is not uniform.) 300 Some URI schemes are more problematic. For example, one might think 301 that a URN within a URN wouldn't be useful. But it might be possible 302 where the assignment of names in a URN namespace are not, in 303 practice, permanent, or that one might want to refer to the 304 assignment as of a given date. In this case, it is possible to use a 305 "urn" within a "duri", e.g., 307 urn:duri:2000:urn:ietf:std:50 309 might be used to refer to "the document that was STD 50 in effect as 310 of the first instant of 2000". [5] 312 One might consider using "tdb" with "data" to designate concepts that 313 can be described uniquely briefly inline. For example, 315 urn:tdb:2001:data:,The%2520US%2520president 317 names the concept described by the (text/plain) string "The US 318 president" at the very first instant of 2001. (Note the awkward 319 double quoting of space as "%20" and then the "%" as "%25".) Of 320 course, this practice is only useful if the referent of the data is 321 (or was at the time) completely unique. Since "data" does contain a 322 way to designate content-language, the string in question would have 323 to not be ambiguous as to its language. In the case of 'data', there 324 is no assigning authority at all; the interpretation of the 'tdb' URN 325 depend on the interpreting community. 327 5.2 Useful dates 329 Dates in the future are suspect, because the meaning of the duri or 330 tdb cannot readily be determined in advance reliably. Dates prior to 331 the actual assignment of the resource to the embedded URI (and, 332 certainly, dates far in the past) SHOULD NOT be used, because the 333 meaning of the reference is left in question. For example, using 334 http URIs before a web service was available at the given URI doesn't 335 make much sense. 337 However, although these practices are NOT RECOMMENDED, there is no 338 assurance that they haven't been used; by itself, a duri/tdb does not 339 constitute an assertion that the encoded-URI was available or 340 assigned at the date specified. 342 Note that the use of the "very first instant" means that a duri/tdb 343 using only a year must give a year greater than the first year in 344 which the corresponding URI was published; if a web page is published 345 in the middle of 2001, then "duri:2001:..." would be inappropriate. 347 5.3 Free assignment 349 Because of the many possible schemes that can be used in the 350 portion, there should be no difficulty in almost any 351 computational process being able to assign duris or tdbs at will. Of 352 course, it is necessary for there to be some resource which is 353 available at some point in time, and to have a clock which is 354 accurate to the granularity of the frequency of assignment. 356 5.4 Resolution 358 There no accurate resolution servers for duri or tdb URNs. However, 359 duri might be "resolvable" in the sense that a resource that was 360 accessed at a point in time might have the result of that access 361 cached or archived in an Internet archive service. See, for example, 362 the "Internet Archive" project [10]. A "tdb" is only resolvable in 363 the sense that if the corresponding duri can be resolved, it may be 364 possible that the result can be accessed and interpreted. 366 Clients without access to an Internet archive service might take the 367 decoded of a duri and attempt resolution of *that* 368 identifier. This will give an approximation whose reliability 369 depends on the amount of time elapsed since the date indicated. 371 5.5 Why Names with Semantics? 373 There are a number of proposals for URN schemes that create otherwise 374 unbound "names", where the URN scheme only provides for uniqueness. 375 Neither "duri" nor "tdb" intrinsically have the property that the 376 names assigned are without any resolution semantics. This is 377 intentional; it's difficult to create names that carry no semantics 378 whatsoever about the authority that assigned the name and the 379 intention of the authority for what the name should designate. 381 5.6 Avoiding MetaData 383 One might consider the date in a duri/tdb to be just one piece of 384 additional metadata about the encoded-URI, and consider adding other 385 pieces of metadata as annotation. 387 However, the use of the date in a duri/tdb is intended primarily as a 388 mechanism of accomplishing uniqueness over time. No other bit of 389 metadata or description readily fills that purpose. Further, the 390 date is not descriptive (an assertion about the encoded-URI) but 391 merely refining. 393 5.7 Avoiding duri and tdb 395 Many applications of URIs already provide a context of date. For 396 example, one could imagine a hypertext system where the URIs 397 contained within a document were intended to refer to the resources 398 as of the date of the enclosing document. This would be a reasonable 399 interpretation of URIs within an Internet archive system, for 400 example. 402 And some applications of URIs arguably already contain the level of 403 interpretive indirection that is explicit with "tdb". For example, 404 one might consider the use of URIs as namespace names within XML [8] 405 as a reference to the "thing described by" the URI used. 407 5.8 tdb and RDF 409 The Resource Description Framework [9] is an XML-based framework for 410 describing assertions. RDF uses URIs to identify the objects being 411 described and XML-based tags to describe the relationships between 412 them. 414 The relations in RDF, however, may already provide for the "thing 415 described by" indirection. The example in Section 3.2.1 of [9] 416 suggests the model for the sentence "The students in course 6.001 are 417 Amy, Tim and Mary" might be written in RDF/XML as 418 419 420 421 422 423 424 425 426 427 428 430 but the resources listed are web pages (served by HTTP) and the 431 class and students are the "things described by" those web pages. 433 Of course, RDF contains mechanisms that allow this to be said 434 directly. 436 5.9 tdb and levels of indirection 438 The "tdb" scheme introduces a level of semantic indirection. The 439 puzzles and confusions about use and mention, name and reference, and 440 levels of indirection have been puzzling and amusing for quite a 441 while. 443 "It's long," said the Knight, "but it's very, very beautiful. 444 Everybody that hears me sing it--either it brings tears into their 445 eyes, or else--" 446 "Or else what?" said Alice, for the Knight had made a sudden 447 pause. 448 "Or else it doesn't, you know. The name of the song is called 449 'Haddock's Eyes.'" 450 "Oh, that's the name of the song, is it?" Alice said, trying to 451 feel interested. 452 "No, you don't understand," the knight said, looking a little 453 vexed. "That's what the name is called. The name really is 'The 454 Aged Aged Man.'" 455 "Then I ought to have said 'That's what the song is called'?" 456 Alice corrected herself. 457 "No, you oughtn't: that's quite another thing! The song is called 458 'Ways and Means': but that's only what it's called, you know!" 459 "Well, what is the song, then?" said Alice, who was by this time 460 completely bewildered. 461 "I was coming to that," the Knight said. "The song really is 'A- 462 sitting On A Gate': and the tune's my own invention." [11] 464 6. URN Specification Templates 466 6.1 duri Specification Template 468 o Namespace ID: 469 "duri" requested. 471 o Registration Information: 472 Registration Version: 1 473 Registration Date: 2001-08-19 475 o Declared registrant of the namespace: 476 Larry Masinter 478 o Declaration of syntactic structure: 479 Briefly, the syntax is 480 urn:duri:: 481 The syntax is described in this document. 483 o Relevant ancillary documentation: 484 (See References of this document) 486 o Identifier uniqueness considerations: 487 Uniqueness is guaranteed by the structure of adding a designation 488 of a specific instant to a URI. However, URIs with ambiguous 489 interpretation at any given instant (e.g., "file" URIs without a 490 given host name) will not be unique. 492 o Identifier persistence considerations: 493 The designation of a dated URI is completely persistent for all 494 time. 496 o Process of identifier assignment: 497 Any date can be used with any URI independently by anyone. 499 o Process of identifier resolution: 500 Identifiers can only be resolved approximately. See Section 4.3. 502 o Conformance with URN Syntax: 503 Note that the use of "/" for hierarchy, while discouraged in the 504 URN specification, is allowed in duris. 506 o Rules for Lexical Equivalent: 507 For dates, YYYY is equivalent to YYYY01, YYYYMM is equivalent to 508 YYYYMM01, while YYYYMMDD is equivalent to YYYYMMDD0... followed 509 by any number of 0's. In considering equivalence of the encoded 510 URI, if two duris with equivalent dates contain lexically 511 equivalent URIs, the duris are equivalent. 513 o Validation mechanism: 514 Dates should be reasonable and meet the syntactic requirements. 515 The URI encoded within should meet the syntactic requirements of 516 the URI scheme used. 518 o Scope: Global. 520 6.2 tdb Specification Template 522 o Namespace ID: 523 "tdb" requested. 525 o Registration Information: 526 Registration Version: 1 527 Registration Date: 2001-08-19 529 o Declared registrant of the namespace: 530 Larry Masinter 532 o Declaration of syntactic structure: 533 Briefly, the syntax is 534 urn:tdb:: 535 The syntax is described in this document. 537 o Relevant ancillary documentation: 538 (See References of this document) 540 o Identifier uniqueness considerations: 541 Uniqueness is guaranteed by the structure of adding a designation 542 of a specific instant to a URI. However, URIs with ambiguous 543 interpretation at any given instant (e.g., "file" URIs without a 544 given host name) will not be unique. 546 o Identifier persistence considerations: 547 The designation of a dated URI is completely persistent for all 548 time, although the intent of a resource that is no longer 549 available will be hard to discern. 551 o Process of identifier assignment: 552 Any date can be used with any URI independently by anyone. 554 o Process of identifier resolution: 555 Resolution of "tdb" identifiers requires interpreting the resource 556 identified by the corresponding "duri". See Section 2.2 of this 557 document. 559 o Rules for Lexical Equivalent: 561 As with "duri", see Section 6.1. 563 o Conformance with URN Syntax: 564 As with "duri", see Section 6.1. 566 o Validation mechanism: 567 As with "duri", see Section 6.1. 569 o Scope: 570 Global. 572 7. IANA considerations 574 This document includes two URN NID registrations (sections 5.1 and 575 5.2) that should be entered into the IANA registry of URN NIDs. 577 8. Security Considerations 579 "duri" and "tdb" names are not any more reliable because they are 580 dated. URIs don't contain enough information to supply the authority 581 for deciding what was or wasn't at a given URI at a given date. 583 9. Acknowledgements 585 There have been many discussions over several years on the 586 relationship of URLs, URNs, URIs, resources and resource identifiers, 587 with many contributions. Particular thanks to Aaron Swartz, Brian 588 McBride and Stuart Williams for their recent comments, and to Michael 589 Mealling, who encouraged me to pursue this. 591 References 593 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 595 [2] Berners-Lee, T., "Cool URLs don't change"", 1998. 597 [3] Sollins, K., "Functional Requirements for Uniform Resource 598 Names", RFC 1737, December 1994. 600 [4] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC 601 2550, April 1 1999. 603 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 604 August 1999. 606 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 607 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 608 1998. 610 [7] Bureau International des Poids et Mesures, "International 611 Atomic Time". 613 [8] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 614 Recommendation REC-xml-names, January 1999, . 617 [9] Lassila, O. and R. Swick, "Resource Description Framework (RDF) 618 Model and Syntax Specification", W3C Recommendation REC-rdf- 619 syntax, February 1999, . 621 [10] archive.org, "The Internet Archive: Building an 'Internet 622 Library'", . 624 [11] Carroll, L., "Through the Looking Glass", 1872. 626 Author's Address 628 Larry Masinter 629 Adobe Systems Incorporated 630 345 Park Ave 631 San Jose, CA 95110 632 US 634 Phone: +1 408 536 3024 635 EMail: LMM@acm.org 636 URI: http://larry.masinter.net 638 Full Copyright Statement 640 Copyright (C) The Internet Society (2002). All Rights Reserved. 642 This document and translations of it may be copied and furnished to 643 others, and derivative works that comment on or otherwise explain it 644 or assist in its implementation may be prepared, copied, published 645 and distributed, in whole or in part, without restriction of any 646 kind, provided that the above copyright notice and this paragraph are 647 included on all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by removing 649 the copyright notice or references to the Internet Society or other 650 Internet organizations, except as needed for the purpose of 651 developing Internet standards in which case the procedures for 652 copyrights defined in the Internet Standards process must be 653 followed, or as required to translate it into languages other than 654 English. 656 The limited permissions granted above are perpetual and will not be 657 revoked by the Internet Society or its successors or assigns. 659 This document and the information contained herein is provided on an 660 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 661 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 662 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 664 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Acknowledgement 668 Funding for the RFC Editor function is currently provided by the 669 Internet Society.