idnits 2.17.1 draft-peterson-geopriv-pidf-lo-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 22, 2003) is 7615 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: '1' is defined on line 491, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 531, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-03 == Outdated reference: A later version (-09) exists of draft-ietf-smime-rfc2633bis-03 ** Obsolete normative reference: RFC 3369 (ref. '6') (Obsoleted by RFC 3852) == Outdated reference: A later version (-07) exists of draft-ietf-smime-aes-alg-06 == Outdated reference: A later version (-04) exists of draft-ietf-geopriv-reqs-03 == Outdated reference: A later version (-02) exists of draft-morris-geopriv-core-01 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '12') (Obsoleted by RFC 3986) -- No information found for draft-ietf-geopriv-threats - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. '17') (Obsoleted by RFC 3369, RFC 3370) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: December 21, 2003 June 22, 2003 6 A Presence-based GEOPRIV Location Object Format 7 draft-peterson-geopriv-pidf-lo-00 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 December 21, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a object format for carrying geographical 39 information on the Internet. This location object extends the 40 Presence Information Data Format (PIDF), which was designed for 41 communicating privacy-sensitive presence information and has similar 42 properties. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Location Object Format . . . . . . . . . . . . . . . . . . . 4 48 2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . . 4 49 2.2 Extensions to PIDF for Location and Privacy Policy . . . . . 5 50 2.2.1 'location-info' element . . . . . . . . . . . . . . . . . . 5 51 2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . . . . 6 52 2.2.3 Schema definition . . . . . . . . . . . . . . . . . . . . . 7 53 2.3 Example Location Object . . . . . . . . . . . . . . . . . . 8 54 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . 9 55 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . 9 56 5. Security Considerations . . . . . . . . . . . . . . . . . . 11 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 58 6.1 URN Sub-Namespace Registration for 59 urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . . 11 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 61 A. To Do and Unmet requirements . . . . . . . . . . . . . . . . 14 62 Normative References . . . . . . . . . . . . . . . . . . . . 12 63 Informative References . . . . . . . . . . . . . . . . . . . 12 64 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 67 1. Introduction 69 Geographical location information describes a physical position in 70 the world that may correspond to the past, present or future location 71 of a person or device. Numerous applications used in the Internet 72 today benefit from sharing location information (including mapping/ 73 navigation applications, 'friend finders' on cell phones, and so on). 74 However, such applications may disclose the whereabouts of a person 75 in a manner contrary to the user's preferences. Privacy lapses may 76 result from poor protocol security (which permits eavesdroppers to 77 capture location information), inability to articulate or accommodate 78 user preferences, or similar defects common in existing systems. The 79 privacy concerns surrounding the unwanted disclosure of a person's 80 physical location are among the more serious that confront users on 81 the Internet. 83 Consequently, a need has been identified to convey geographical 84 location information within an object that includes a user's privacy 85 and disclosure preferences and which is protected by strong 86 cryptographic security. Previous work [11] has observed that this 87 problem bears some resembles to the general problem of communicating 88 and securing presence information on the Internet. Presence (which 89 is defined in [10]) provides a real-time communications disposition 90 to a user that have similar requirements for selective distribution 91 and security. 93 Therefore, this document extends the XML-based Presence Information 94 Data Format (PIDF [2]) to allow the encapsulation of location 95 information within a presence document. 97 This document does not invent any format for location information 98 itself. Numerous already existing formats based on civil location, 99 spatial coordinates, and the like have been developed in other 100 standards fora. Instead, this document defines an object that is 101 suitable for both identifying and encapsulating pre-existing location 102 information formats and for providing adequate security and policy 103 controls to regulate the distribution of location information over 104 the Internet. 106 The location object described in this document can be used 107 independently of any 'using protocol' as the term is defined in the 108 GEOPRIV requirements [8]. It is considered an advantage of this 109 proposal that existing presence protocols (such as [13]) would 110 natively accommodate the location object format defined in this 111 document, and be capable of composing location information with other 112 presence information, since this location object is an extension of 113 PIDF. However, any protocol that can carry XML or MIME types can 114 carry PIDF. 116 Some of the requirements in [8] concern data collection and usage 117 policies associated with location objects. This document does not 118 provide a markup suitable for a user to express the necessary privacy 119 preferences as specified by the geopriv requirements. However, this 120 document does demonstrate how an XML-based privacy preference 121 document could be embedded within a PIDF document. 123 2. Location Object Format 125 2.1 Baseline PIDF Usage 127 The GEOPRIV requirements [8] (or REQ for short throughout this 128 section) specify the need for a name for the person, place or thing 129 that location information describes (REQ 2.1). PIDF has such an 130 identifier already, since every PIDF document has "entity" attribute 131 of the "presence" element that signifies the URI of the entity whose 132 presence the document describes. Similarly, if location information 133 is contained in a PIDF document, the URI in the "entity" attribute of 134 the "presence" element indicates the target of that location 135 information. The URI in the "entity" attribute should use the "pres" 136 URI scheme defined in [3]. URIs can serve as "unlinkable pseudonyms" 137 (per REQ 12). 139 PIDF optionally contains a "contact" element that contains a URI 140 where the presentity can be reached by some means of communication 141 (usually, the URI scheme in the value of the "contact" element gives 142 some sense of how the presentity can be reached: if it uses the SIP 143 URI scheme, for example, SIP can be used, and so on). Location 144 information can be provided without any associated means of 145 communication - thus, the "contact" element may or may not be 146 present, as desired by the creator of the PIDF document. 148 PIDF optionally contains a "timestamp" element that designates the 149 time at which the PIDF was created. This element corresponds to REQ 150 2.7a. 152 PIDF contains a "status" element, which is mandatory. "status" 153 contains an optional child element "basic" that describes the 154 presentity's communications disposition (in the very broad terms: 155 either OPEN or CLOSED). For the purposes of this document, it is not 156 necessary for "basic" status to be included. If, however, 157 communications disposition is included in a PIDF document above and 158 beyond geolocation, then "basic" status may appear in a PIDF document 159 that uses these extensions. 161 PIDF also contains a "tuple" element, which is used to uniquely 162 identify a segment of presence information so that changes to this 163 information can be tracked over time (as multiple notifications of 164 presence are received). 166 2.2 Extensions to PIDF for Location and Privacy Policy 168 This XML Schema extends the "status" element of PIDF with a complex 169 element called "geopriv". There are two major subelements that are 170 encapsulated within geopriv: one for location information, and one 171 for usage rules. Both of these subelements are mandatory, and are 172 described in subsequent sections. 174 There are also a few other elements which are contained within the 175 geopriv element in support of the GEOPRIV requirements. 177 2.2.1 'location-info' element 179 Each 'geopriv' element MUST contain one 'location-info' element. A 180 'location-info' element consists of one or more chunks of location 181 information (per REQ 2.5). The format of the location information 182 (REQ 2.6) is identified by the imported XML Schema describing the 183 namespace in question. All PIDF documents that contain a 'geopriv' 184 element MUST contain one or more import directive indicating the XML 185 Schema(s) that will be used as geolocation formats. 187 In order to ensure interoperability of GEOPRIV implementations, it is 188 necessary to select a baseline location format that all compliant 189 implementations support (see REQ 3.1). At this time, there is not 190 sufficient working group consensus within the GEOPRIV WG to award 191 this distinction to any particular location format. Without applying 192 any particular selection criteria (apart from REQs 2.5.1), this 193 document works from the assumption that GML 3.0 [14] will be this 194 mandatory format (MUST implement for all PIDF implementations 195 supporting the 'geopriv' element). 197 The Geography Markup Language (GML) is an extraordinarily thorough 198 and versatile system for modeling all manner of geographic topologies 199 and objects. The simplest package for GML supporting location 200 information is the 'feature.xsd' schema. Various format descriptions 201 (including latitude/longitude based location information) is 202 supported by Feature (see section 7.4.1.4 of [14] for examples). 203 This resides here: 205 urn:opengis:specification:gml:schema-xsd:feature:v3.0 206 208 Note that by importing the Feature schema, necessary GML baseline 209 schemas are transitively imported. 211 Complex features (such as modeling topologies and polygons, 212 directions and vectors, temporal indications of the time for which a 213 particular location is valid for a target) are also available in GML, 214 but require importing additional schemas. For the purposes of this 215 document, only support for the feature.xsd GML schema is REQUIRED. 217 2.2.2 'usage-rules' element 219 At the time this document was written, the policy requirements for 220 GEOPRIV objects were not definitively completed. However, the 221 'usage-rules' element exists to satisfy REQ 2.8, and the requirements 222 of the GEOPRIV policy requirements [9] document. Each 'geopriv' 223 element SHOULD contain one 'usage-rules' element - Location 224 Generators MAY not include this element ONLY IF users have 225 specifically requested that all sub-elements given below are 226 unnecessary to protect this Location Object. 228 Following to that document (Section 3.1), there are three fields that 229 need to be expressible in Location Objects throughout their lifecycle 230 (from Generator to Recipient): one field that limit retransmission, 231 one that limit retention, and one that contains a reference to 232 external rulesets. Those three fields are instantiated here by the 233 first three elements. The fourth element provides a generic space 234 for human-readable policy directives. Any of these fields MAY be 235 present in a Location Object 'usage-rules' element; none are required 236 to be. 238 'retransmission-allowed': When the value of this element is 'no', 239 the Recipient of this Location Object is not permitted to share 240 the enclosed Location Information, or the object as a whole, with 241 other parties. When the value of this element is 'yes', sharing 242 this Location Object or information is permitted (barring an 243 existing agreement or obligation to the contrary). By default, 244 the value MUST be assumed to be 'no'. Implementations MUST 245 include this field, with a value of 'no', if the Rule Maker 246 specifies no preference. 248 'retention-expires': This field specifies an absolute date at 249 which time the Recipient is no longer permitted to possess the 250 location information and its encapsulating Location Object - both 251 may be retained only up until the time specified by this field. 252 By default, the value MUST be assumed to be twenty-four hours from 253 the 'timestamp' element in the PIDF document, if present; if the 254 'timestamp' element is not present, then twenty-four hours from 255 the time at which the Location Object is received. If the value 256 in the 'retention-expires' element has already passed when the 257 Location Recipient receives the Location Object, the Recipient 258 MUST discard the Location Object immediately. 260 'ruleset-reference': This field contains a URI to a network server 261 that holds rules appropriate for this Location Object. This 262 SHOULD be an HTTPS URI, and the server that holds these rules MUST 263 authenticate any attempt to access these rules - usage rules 264 themselves may divulge private information about a Target or Rule 265 Maker. Location Recipients SHOULD NOT attempt to dereference this 266 URI - it is intended only for the consumption of Location Servers. 268 'note-well': This field contains a block of text containing 269 further generic privacy directives. These directives are intended 270 to be human-readable only, not to be processed by any automaton. 272 2.2.3 Schema definition 274 Note that the XML namespace [4] for this extension to PIDF contains a 275 version number 1.0 (as per REQ 2.10). 277 278 283 284 285 287 289 291 292 294 295 296 298 299 301 302 303 305 307 309 311 313 314 316 317 318 319 320 321 323 324 325 326 327 328 329 331 333 2.3 Example Location Object 335 The following XML instance document is an example of the use of a 336 simple GML 3.0 markup with a few of the policy directives specified 337 above within a PIDF document. 339 340 344 345 2003-06-22T20:57:29Z 346 347 348 349 350 351 31:56:00S 115:50:00E 352 353 354 355 356 no 357 2003-06-23T04:57:29Z 358 359 360 361 362 364 Note that this shows a PIDF document without any MIME headers or 365 security applied to it (see Section 4 below). 367 3. Carrying PIDF in a Using Protocol 369 A PIDF document is an XML document, and therefore PIDF might be 370 carried in any protocol that is capable of carrying XML. A MIME type 371 has also been registered for PIDF: 'application/cpim-pidf+xml'. PIDF 372 may therefore be carried as a MIME body in protocols that use MIME 373 (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME 374 headers, including a Content-Type of 'application/cpim-pidf+xml". 376 Further specification of the behavior of using protocols (including 377 subscribing to or requesting presence information) is outside the 378 scope of this document. 380 4. Securing PIDF 382 There are a number of ways in which XML documents can be secured. 383 XML itself supports several ways of partially securing documents, 384 including element-level encryption and digital signature properties. 386 For the purposes of this document, only the securing of a PIDF 387 document as a whole, rather than element-by-element security, is 388 considered. None of the requirements [8] suggest that only part of 389 the information in a location object might need to be protected while 390 other parts are unprotected - virtually any such configuration would 391 introduce potentials for privacy leakage. Consequently, the use of 392 MIME-level security is appropriate. 394 S/MIME [5] allows security properties (including confidentiality, 395 integrity and authentication properties) to be applied to the 396 contents of a MIME body. Therefore, all PIDF implementations that 397 support the XML Schema extensions for location information described 398 in this document MUST support S/MIME, and in particular must support 399 the CMS [6] EnvelopedData and SignedData messages, which are used for 400 encryption and digital signatures respectively. It is believed that 401 this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, 14.4. 403 Additionally, all implementations MUST implement the AES encryption 404 algorithm for S/MIME, as specified in [7] (and per REQ 15.1). Of 405 course, implementations MUST also support the baseline encryption and 406 digital signature algorithms described in the S/MIME specification. 408 S/MIME generally entails the use of X.509 [16] certificates. In 409 order to encrypt a request for a particular destination end-to-end 410 (i.e. to a Location Recipient), the Location Generator must possess 411 credentials (typically an X.509 certificate) that have been issued to 412 the Location Recipient. 414 S/MIME was designed for end-to-end security between email peers that 415 communicate through multiple servers (i.e mail transfer agents) that 416 do not modify message bodies. There is, however, at least one 417 instance in which Location Servers modify Location Objects - namely 418 when Location Servers enforce policies on behalf of the Rule Maker. 419 For example, a Rule Maker may specify that Location Information 420 should be coarsened (made less specific) before it is transmitted to 421 particular recipients. If the Location Server were unable to modify 422 a Location Object, because it was encrypted, signed, or both, it 423 would be unable to accomplish this function. Consequently, when a 424 Location Generator wants to allow a Location Server to modify such 425 messages, they MAY encrypt such messages with keys issued to the 426 Location Server (the signature, of course, can still be created with 427 keying material from the Location Generator's certificate). After 428 modifying the Location Object, the Location Server can resign the 429 Object with its own credentials (encrypting it with any keys issued 430 to the Location Recipient, if they are known to the Server). 432 Note that policies for data collection and usage of location 433 information, in so far as they are carried within a location object, 434 are discussed in Section 2.2.2. 436 5. Security Considerations 438 The threats to which an Internet service carrying geolocation might 439 be subjected are detailed in [15]. The requirements that were 440 identified in that analysis of the threat model were incorporated 441 into [8], in particular within Section 7.4. This document aims to be 442 compliant with the security requirements derived from those two 443 undertakings in so far as they apply to the location object itself. 445 Security of the location object defined in this document, including 446 normative requirements for implementations, is discussed in Section 447 4. This security focuses on end-to-end integrity and confidentiality 448 properties that are applied to a location object for its lifetime via 449 S/MIME. 451 Security requirements associated with using protocols (including 452 authentication of subscribers to geographical information, and so on) 453 are outside the scope of this document. 455 6. IANA Considerations 457 6.1 URN Sub-Namespace Registration for 458 urn:ietf:params:xml:ns:pidf:geopriv10 460 This section registers a new XML namespace, as per the guidelines in 461 [4]. 463 URI: The URI for this namespace is 464 urn:ietf:params:xml:ns:pidf:geopr. 466 Registrant Contact: IETF, GEOPRIV working group, 467 (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). 469 XML: 471 BEGIN 472 473 475 476 477 479 GEOPRIV PIDF Extensions 480 481 482

PIDF Extensions of Geographical Information and Privacy

483

urn:ietf:params:xml:ns:pidf:geopriv10

484

See RFCXXXX.

485 486 487 END 489 Normative References 491 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 492 levels", RFC 2119, March 1997. 494 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 495 J. Peterson, "CPIM Presence Information Data Format", draft- 496 ietf-impp-cpim-pidf-07 (work in progress), August 2001. 498 [3] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf- 499 impp-pres-03 (work in progress), May 2003. 501 [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana- 502 xmlns-registry-05 (work in progress), June 2003. 504 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 505 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 507 [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 508 2002. 510 [7] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm 511 and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 512 (work in progress), January 2003. 514 Informative References 516 [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 517 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 518 in progress), February 2003. 520 [9] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 521 Protections for Geopriv Location Object", draft-morris-geopriv- 522 core-01 (work in progress), March 2003. 524 [10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 525 Instant Messaging", RFC 2778, February 2000. 527 [11] Peterson, J., "A Presence Architecture for the Distribution of 528 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 529 in progress), February 20003. 531 [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 532 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 533 1998. 535 [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 536 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 537 Session Initiation Protocol", RFC 3261, May 2002. 539 [14] OpenGIS, "", OGC 02-023r4, January 2003, . 542 [15] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat 543 Analysis of the geopriv Protocol", draft-ietf-geopriv-threats- 544 00 (work in progress), February 2003. 546 [16] ITU-T, "Recommendation X.509 - Open Systems Interconnection - 547 The Directory: Authentication", ITU-T X.509, June 1997, . 550 [17] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 551 December 2001. 553 Author's Address 555 Jon Peterson 556 NeuStar, Inc. 557 1800 Sutter St 558 Suite 570 559 Concord, CA 94520 560 US 562 Phone: +1 925/363-8720 563 EMail: jon.peterson@neustar.biz 564 URI: http://www.neustar.biz/ 566 Appendix A. To Do and Unmet requirements 568 Today, this document makes a very half-hearted recommendation for 569 GML3.0 as the mandatory-to-implement geolocation format for Location 570 Objects. Much more discussion is needed of the merits and flaws of 571 this approach. We also need to identify an appropriate worldwide 572 postal address format (surely there are existing XML standards for 573 this that we can reuse). 575 Below are various GEOPRIV requirements [8] that currently are not met 576 by this document. These requirements may be met in future versions 577 of the document. 579 REQ 1.5: Requesting location information is deferred to the using 580 protocol in this paradigm of GEOPRIV. The Location Object 581 contains no support for this feature either way. 583 REQ 1.8: The S/MIME mechanism in this document, in so far as it 584 uses X.509, may be too heavyweight to accommodate constrained 585 devices with little memory or processing power. There are 586 variants of S/MIME that do not use certificates for various 587 security function, but instead use symmetric keys (see [17]), and 588 which would consequently be a better fit for constrained devices. 590 REQ 2.2: The identity of the Location Recipient should not have to 591 be known to the Location Generator - it is possible that the 592 Generator publishes its location information to a Location Server 593 that enforces policies relevant to various Recipients without 594 informing the Generator that location information has been 595 requested. Carrying the identity of the recipient is deferred to 596 the using protocol in this paradigm of GEOPRIV. 598 REQ 2.3 & 2.4: These requirements would need to be further 599 specified before it would be possible for a solution document to 600 satisfy them. It is not clear what these credentials are, nor why 601 the Location Generator would possess them and place them inside 602 Location Objects. 604 XML Schemas and examples have not been validated. 606 Appendix B. Acknowledgments 608 This document was produced with the assistance of many members of the 609 GEOPRIV IETF working group. 611 Full Copyright Statement 613 Copyright (C) The Internet Society (2003). All Rights Reserved. 615 This document and translations of it may be copied and furnished to 616 others, and derivative works that comment on or otherwise explain it 617 or assist in its implementation may be prepared, copied, published 618 and distributed, in whole or in part, without restriction of any 619 kind, provided that the above copyright notice and this paragraph are 620 included on all such copies and derivative works. However, this 621 document itself may not be modified in any way, such as by removing 622 the copyright notice or references to the Internet Society or other 623 Internet organizations, except as needed for the purpose of 624 developing Internet standards in which case the procedures for 625 copyrights defined in the Internet Standards process must be 626 followed, or as required to translate it into languages other than 627 English. 629 The limited permissions granted above are perpetual and will not be 630 revoked by the Internet Society or its successors or assigns. 632 This document and the information contained herein is provided on an 633 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 634 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 635 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 636 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 637 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Acknowledgement 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.