idnits 2.17.1 draft-ietf-impp-pres-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 19, 2003) is 7641 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: '6' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-impp-srv-02 ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '6') == Outdated reference: A later version (-09) exists of draft-ietf-smime-rfc2633bis-03 ** Obsolete normative reference: RFC 3369 (ref. '9') (Obsoleted by RFC 3852) == Outdated reference: A later version (-07) exists of draft-ietf-smime-aes-alg-06 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMPP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: November 17, 2003 May 19, 2003 6 Common Profile for Presence (CPP) 7 draft-ietf-impp-pres-03 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 November 17, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Presence is defined in RFC2778 [5]. Today, numerous presence 39 protocols are in use (largely as components of commercial instant 40 messaging services), and little interoperability between services 41 based on these protocols has been achieved. This specification 42 defines common semantics and data formats for presence to facilitate 43 the creation of gateways between presence services. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Abstract Presence Service . . . . . . . . . . . . . . . . . 4 50 3.1 Overview of the Presence Service . . . . . . . . . . . . . . 4 51 3.2 Identification of PRESENTITIES and WATCHERS . . . . . . . . 6 52 3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 7 53 3.3 Format of Presence Information . . . . . . . . . . . . . . . 7 54 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 7 55 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 7 56 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 8 57 3.4.3 Subscribe Operation (with Zero Duration) . . . . . . . . . . 8 58 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 60 5.1 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 10 61 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 63 A. PRES URI IANA Registration Template . . . . . . . . . . . . 11 64 A.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . 11 65 A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 11 66 A.3 Character encoding considerations . . . . . . . . . . . . . 12 67 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 12 68 A.5 Applications and/or protocols which use this URI scheme 69 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 A.6 Interoperability considerations . . . . . . . . . . . . . . 12 71 A.7 Security considerations . . . . . . . . . . . . . . . . . . 12 72 A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 12 73 A.9 Person & email address to contact for further information . 12 74 A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 13 75 A.11 Applications and/or protocols which use this URI scheme 76 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 13 78 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 13 79 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 13 80 Normative References . . . . . . . . . . . . . . . . . . . . 10 81 Informative References . . . . . . . . . . . . . . . . . . . 11 82 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 83 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 Presence is defined in RFC2778 [5]. Today, numerous presence 88 protocols are in use (largely as components of commercial instant 89 messaging services), and little interoperability between services 90 based on these protocols has been achieved. This specification 91 defines semantics and data formats for common services of presence to 92 facilitate the creation of gateways between presence services: a 93 common profile for presence (CPP). 95 Service behavior is described abstractly in terms of operations 96 invoked between the consumer and provider of a service. Accordingly, 97 each presence service must specify how this behavior is mapped onto 98 its own protocol interactions. The choice of strategy is a local 99 matter, providing that there is a clear relation between the abstract 100 behaviors of the service (as specified in this memo) and how it is 101 faithfully realized by a particular presence service. For example, 102 one strategy might transmit presence information as key/value pairs, 103 another might use a compact binary representation, and a third might 104 use nested containers. 106 The parameters for each operation are defined using an abstract 107 syntax. Although the syntax specifies the range of possible data 108 values, each presence service must specify how well-formed instances 109 of the abstract representation are encoded as a concrete series of 110 bits. 112 In order to provide a means for the preservation of end-to-end 113 features (especially security) to pass through presence 114 interoperability gateways, this specification also provides 115 recommendations for presence document formats that could be employed 116 by presence protocols. 118 2. Terminology 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 122 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 123 described in RFC2119 [1] and indicate requirement levels for 124 compliant implementations. 126 This memos makes use of the vocabulary defined in RFC2778 [5]. Terms 127 such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in the 128 same meaning as defined therein. 130 The term 'gateway' used in this draft denotes a network element 131 responsible for interworking between diverse presence protocols. 132 Although the presence protocols themselves are diverse, under the 133 model used in this document these protocols can carry a common 134 payload that is relayed by the gateway. Whether these interworking 135 intermediaries should be called 'gateways' or 'relays' is therefore 136 somewhat debatable; for the purposes of this document, they are 137 called 'CPP gateways'. 139 The term 'presence service' also derives from RFC2778, but its 140 meaning changes slightly due to the existence of gateways in the CPP 141 model. When a client sends a operation to a presence service, that 142 service might either be an endpoint or an intermediary such as a CPP 143 gateway - in fact, the client should not have to be aware which it is 144 addressing, as responses from either will appear the same. 146 This document defines operations and attributes of an abstract 147 presence protocol. In order for a compliant protocol to interface 148 with a presence gateway, it must support all of the operations 149 described in this document (i.e. the presence protocol must have 150 some message or capability that provides the function described by 151 all given operations). Similarly, the attributes defined for these 152 operations must correspond to information available in the presence 153 protocol in order for the protocol to interface with gateways defined 154 by this specification. Note that these attributes provide only the 155 minimum possible information that needs to be specified for 156 interoperability - the functions in a presence protocol that 157 correspond to the operations described in this document can contain 158 additional information that will not be mapped by CPP. 160 3. Abstract Presence Service 162 3.1 Overview of the Presence Service 164 When an application wants to subscriber to the presence information 165 associated with a PRESENTITY (in order to receive periodic 166 notifications of presence information), it invokes the subscribe 167 operation, e.g., 169 +-------+ +-------+ 170 | | | | 171 | appl. | -- subscribe ----> | pres. | 172 | | | svc. | 173 +-------+ +-------+ 175 The subscribe operation has the following attributes: watcher, 176 target, duration, SubscriptID and TransID. The 'watcher' and 177 'target' identify the WATCHER and PRESENTITY, respectively, using the 178 identifiers described in Section 3.2. The duration specifies the 179 maximum number of seconds that the SUBSCRIPTION should be active 180 (which may be zero, in which case this is a one-time request for 181 presence information). The SubscriptID creates a reference to the 182 SUBSCRIPTION that is used when unsubscribing. The TransID is a 183 unique identifier used to correlate the subscribe operation with a 184 response operation. Gateways should be capable of handling TransIDs 185 and SubscriptIDs up to 40 bytes in length. 187 Upon receiving a subscribe operation, the service immediately 188 responds by invoking the response operation containing the same 189 TransID, e.g., 191 +-------+ +-------+ 192 | | | | 193 | appl. | <----- response -- | pres. | 194 | | | svc. | 195 +-------+ +-------+ 197 The response operation has the following attributes: status, TransID, 198 and duration. 'status' indicates whether the subscribe operation has 199 succeeded or failed. The TransID of the response operation 200 corresponds to the TransID of the subscription operation to which it 201 is responding. The 'duration' attribute specifies the number of 202 seconds for which the subscription will be active (which may differ 203 from the value requested in the subscribe operation). 205 If the response operation indicates success, the service immediately 206 invokes the notify operation to communicate the presence information 207 to the WATCHER, e.g., 209 +-------+ +-------+ 210 | | | | 211 | appl. | <------- notify -- | pres. | 212 | | | svc. | 213 +-------+ +-------+ 215 The notify operation has the following attributes: watcher, target, 216 and TransID. The values of 'watcher' and 'target' are identical to 217 those given in the subscribe operation that triggered this notify 218 operation. The TransID is a unique identifier for this notification. 220 The notify operation also has content, namely PRESENCE INFORMATION. 221 Content details are specified in in Section 3.3. 223 If the duration parameter is non-zero, then for up to the specified 224 duration, the service invokes the notify operation whenever there are 225 any changes to the PRESENTITY's presence information. Otherwise, 226 exactly one notify operation is invoked, achieving a one-time poll of 227 the presence information. Regardless, there is no application 228 response to the notify operation (i.e., the application does not 229 invoke a response operation when a notify operation occurs) defined 230 in CPP. 232 The application may prematurely cancel a subscription by re-invoking 233 the subscribe operation (as described above) with a duration of 0 and 234 the same SubscriptID as the original subscribe operation , e.g., 236 +-------+ +-------+ 237 | | | | 238 | appl. | -- subscribe 0 --> | pres. | 239 | | | svc. | 240 +-------+ +-------+ 242 Note that a notify operation will be invoked when a subscription is 243 prematurely canceled in this fashion; this notification may be 244 discarded by the watcher. 246 The service immediately responds by invoking the response operation 247 containing the same TransID; e.g., 249 +-------+ +-------+ 250 | | | | 251 | appl. | <----- response -- | pres. | 252 | | | svc. | 253 +-------+ +-------+ 255 Note that this specification assumes that CPP-compliant presence 256 protocols provide reliable message delivery; there are no 257 application-layer message delivery assurance provisions in this 258 specification. 260 3.2 Identification of PRESENTITIES and WATCHERS 262 A PRESENTITY is specified using the PRES URI scheme, which is further 263 described in Appendix A. An example would be: 264 "pres:fred@example.com" 266 WATCHERs identify themselves in the same manner as PRESENTITIES; that 267 is, with a pres URI. 269 3.2.1 Address Resolution 271 A presence service client determines the next hop to forward an 272 operation to by resolving the domain name portion of the service 273 destination. Compliant implementations SHOULD follow the guidelines 274 for dereferencing URIs given in [2]. 276 3.3 Format of Presence Information 278 This specification defines an abstract interoperability mechanism for 279 presence protocols; the message content definition given here 280 pertains to semantics rather than syntax. However, some important 281 properties for interoperability can only be provided if a common end- 282 to-end format for presence is employed by the interoperating presence 283 protocols, especially with respect to security. In order to maintain 284 end-to-end security properties, applications that send notification 285 operations through a CPP gateway MUST support the format defined in 286 PIDF [4]. Applications MAY support other content formats. 288 CPP gateways MUST be capable of relaying the body of a notification 289 operation between supported presence protocols without needing to 290 modify or inspect the content. 292 3.4 The Presence Service 294 An implementation of the service must maintain information about both 295 presence information and continual operations (like periodic 296 notification) in persistent storage. 298 Note that the subscription-identifier attribute used by the subscribe 299 operation is potentially long-lived. Accordingly, the values 300 generated for this parameter should be unique across a significant 301 duration of time. The SubscriptID parameter should be intrinsically 302 globally unique over time, not merely unique among operations sent to 303 or from a particular WATCHER and PRESENTITY. 305 3.4.1 The Subscribe Operation 307 When an application wants to subscribe to the presence information 308 associated with a PRESENTITY, it invokes the subscribe operation. 310 When the service is informed of the subscribe operation, it performs 311 these steps: 313 1. If the watcher or target parameter does not refer to a valid 314 PRESENTITY, a response operation having status "failure" is 315 invoked. 317 2. If access control does not permit the application to request this 318 operation, a response operation having status "failure" is 319 invoked. 321 3. If the duration parameter is non-zero, and if the watcher and 322 target parameters refer to an in-progress subscribe operation for 323 the application, a response operation having status "failure" is 324 invoked. 326 4. Otherwise, if the service is able to successfully deliver the 327 message: 329 A response operation having status "success" is immediately 330 invoked. (If the service chooses a different duration for the 331 subscription then it conveys this information in the response 332 operation.) 334 A notify operation, corresponding to the target's presence 335 information, is immediately invoked for the watcher. 337 For up to the amount of time indicated by the duration 338 parameter of the notify operation (measured from the time that 339 the subscribe operation was received), if the target's 340 presence information changes, and if access control allows, a 341 notify operation is invoked for the watcher. 343 Note that if the duration parameter is zero-valued, then the 344 subscribe operation is making a one-time poll of the presence 345 information. Accordingly, the final step above (continued 346 notifications for the duration of the subscription) does not occur. 348 When the service invokes a response operation as a result of this 349 processing, the transID parameter is identical to the value found in 350 the subscribe operation invoked by the application. 352 3.4.2 The Notify Operation 354 The service invokes the notify operation whenever the presence 355 information associated with a PRESENTITY changes and there are 356 subscribers requesting notifications for that PRESENTITY. 358 There is no application response to the notify operation. 360 3.4.3 Subscribe Operation (with Zero Duration) 362 When an application wants to terminate a subscription, it issues a 363 SUBSCRIBE 0 with the SubscriptID of an existing subscription. Note 364 that an notify operation will be invoked by the presentity when a 365 subscription is canceled in this fashion; this notification can be 366 discarded by the watcher. There is no independent UNSUBSCRIBE 367 operation. 369 When an application wants to directly request presence information to 370 be supplied immediately without initiating any persistent 371 subscription, it issues a SUBSCRIBE 0 with a new SubscriptID. There 372 is no independent FETCH operation. 374 4. Security Considerations 376 Detailed security considerations for presence protocols given in 377 RFC2779 (in particular, requirements are given in sections 5.1 378 through 5.3 with some motivating discussion in 8.2). 380 CPP defines an interoperability function that is employed by gateways 381 between presence protocols. CPP gateways MUST be compliant with the 382 minimum security requirements of the presence protocols with which 383 they interface. 385 The introduction of gateways to the security model of presence in 386 RFC2779 also introduces some new risks. End-to-end security 387 properties (especially confidentiality and integrity) between 388 presentities and watchers that interface through a CPP gateway can 389 only be provided if a common presence format (such as the format 390 described in [4]) is supported by the protocols interfacing with the 391 CPP gateway. 393 When end-to-end security is required, the notify operation MUST use 394 PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with 395 encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS 396 SignedData). 398 The S/MIME algorithms are set by CMS [9]. The AES [10] algorithm 399 should be preferred, as it is expected that AES best suits the 400 capabilities of many platforms. However, an IETF specificationfor 401 this is still incomplete as of the time of this writing. 403 When PRES URIs are placed in presence protocols, they convey the 404 identity of the sender and/or the recipient. In some cases, 405 anonymous messaging may be desired. Such a capability is beyond the 406 scope of this specification. 408 5. IANA Considerations 410 The IANA assigns the "pres" URI scheme. 412 5.1 The PRES URI Scheme 414 The Presence (PRES) URI scheme designates an Internet resource, 415 namely a PRESENTITY or WATCHER. 417 The syntax of a PRES URI is given in Appendix A. 419 6. Contributors 421 Dave Crocker edited earlier versions of this document. 423 The following individuals made substantial textual contributions to 424 this document: 426 Athanassios Diacakis (thanos.diacakis@openwave.com) 428 Florencio Mazzoldi (flo@networkprojects.com) 430 Christian Huitema (huitema@microsoft.com) 432 Graham Klyne (gk@ninebynine.org) 434 Jonathan Rosenberg (jdrosen@dynamicsoft.com) 436 Robert Sparks (rsparks@dynamicsoft.com) 438 Hiroyasu Sugano (suga@flab.fujitsu.co.jp) 440 Normative References 442 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 443 levels", RFC 2119, March 1997. 445 [2] Crocker, D. and J. Peterson, "Address resolution for Instant 446 Messaging and Presence", draft-ietf-impp-srv-02 (work in 447 progress), February 2003. 449 [3] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 450 2001. 452 [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 453 J. Peterson, "CPIM Presence Information Data Format", draft- 454 ietf-impp-cpim-pidf-07 (work in progress), January 2003. 456 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 457 Instant Messaging", RFC 2778, February 2000. 459 [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 460 Presence Protocol Requirements", RFC 2779, February 2000. 462 [7] Allocchio, C., "GSTN Address Element Extensions in Email 463 Services", RFC 2846, June 2000. 465 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 466 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 468 [9] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 469 2002. 471 Informative References 473 [10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm 474 and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 475 (work in progress), January 2003. 477 Author's Address 479 Jon Peterson 480 NeuStar, Inc. 481 1800 Sutter St 482 Suite 570 483 Concord, CA 94520 484 US 486 Phone: +1 925/363-8720 487 EMail: jon.peterson@neustar.biz 489 Appendix A. PRES URI IANA Registration Template 491 This section provides the information to register the pres: presence 492 URI . 494 A.1 URI scheme name 496 pres 498 A.2 URI scheme syntax 500 The syntax follows the existing mailto: URI syntax specified in 501 RFC2368. The ABNF is: 503 PRES-URI = "pres:" [ to ] [ headers ] 504 to = mailbox 505 headers = "?" header *( "&" header ) 506 header = hname "=" hvalue 507 hname = *urlc 508 hvalue = *urlc 510 A.3 Character encoding considerations 512 Representation of non-ASCII character sets in local-part strings is 513 limited to the standard methods provided as extensions to RFC2822" 514 [3]. 516 A.4 Intended usage 518 Use of the pres: URI follows closely usage of the mailto: URI. That 519 is, invocation of an PRES URI will cause the user's instant messaging 520 application to start, with destination address and message headers 521 fill-in according to the information supplied in the URI. 523 A.5 Applications and/or protocols which use this URI scheme name 525 It is anticipated that protocols compliant with RFC2779, and meeting 526 the interoperability requirements specified here, will make use of 527 this URI scheme name. 529 A.6 Interoperability considerations 531 The underlying exchange protocol used to send an instant message may 532 vary from service to service. Therefore complete, Internet-scale 533 interoperability cannot be guaranteed. However, a service conforming 534 to this specification permits gateways to achieve interoperability 535 sufficient to the requirements of RFC2779. 537 A.7 Security considerations 539 See Section 4. 541 A.8 Relevant publications 543 RFC2779, RFC2778 545 A.9 Person & email address to contact for further information 547 Jon Peterson [mailto:jon.peterson@neustar.biz] 549 A.10 Author/Change controller 551 This scheme is registered under the IETF tree. As such, IETF 552 maintains change control. 554 A.11 Applications and/or protocols which use this URI scheme name 556 Instant messaging service; presence service 558 Appendix B. Issues of Interest 560 This appendix briefly discusses issues that may be of interest when 561 designing an interoperation gateway. 563 B.1 Address Mapping 565 When mapping the service described in this memo, mappings that place 566 special information into the im: address local-part MUST use the 567 meta-syntax defined in RFC2846 [7]. 569 B.2 Source-Route Mapping 571 The easiest mapping technique is a form of source- routing and 572 usually is the least friendly to humans having to type the string. 573 Source-routing also has a history of operational problems. 575 Use of source-routing for exchanges between different services is by 576 a transformation that places the entire, original address string into 577 the im: address local part and names the gateway in the domain part. 579 For example, if the destination INSTANT INBOX is "pepp://example.com/ 580 fred", then, after performing the necessary character conversions, 581 the resulting mapping is: 583 im:pepp=example.com/fred@relay-domain 585 where "relay-domain" is derived from local configuration information. 587 Experience shows that it is vastly preferable to hide this mapping 588 from end-users - if possible, the underlying software should perform 589 the mapping automatically. 591 Appendix C. Acknowledgments 593 The authors would like to acknowledge John Ramsdell for his comments, 594 suggestions and enthusiasm. Thanks to Derek Atkins for editorial 595 fixes. 597 Full Copyright Statement 599 Copyright (C) The Internet Society (2003). All Rights Reserved. 601 This document and translations of it may be copied and furnished to 602 others, and derivative works that comment on or otherwise explain it 603 or assist in its implementation may be prepared, copied, published 604 and distributed, in whole or in part, without restriction of any 605 kind, provided that the above copyright notice and this paragraph are 606 included on all such copies and derivative works. However, this 607 document itself may not be modified in any way, such as by removing 608 the copyright notice or references to the Internet Society or other 609 Internet organizations, except as needed for the purpose of 610 developing Internet standards in which case the procedures for 611 copyrights defined in the Internet Standards process must be 612 followed, or as required to translate it into languages other than 613 English. 615 The limited permissions granted above are perpetual and will not be 616 revoked by the Internet Society or its successors or assigns. 618 This document and the information contained herein is provided on an 619 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 620 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 621 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 622 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 623 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Acknowledgement 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.