idnits 2.17.1 draft-ietf-impp-pres-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: ---------------------------------------------------------------------------- == 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 (February 28, 2003) is 7721 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 D. Crocker 3 Internet-Draft Brandenburg 4 Expires: August 29, 2003 J. Peterson 5 NeuStar 6 February 28, 2003 8 Common Profile for Presence (CPP) 9 draft-ietf-impp-pres-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 Presence is defined in RFC2778 [5]. Today, numerous presence 41 protocols are in use (largely as components of commercial instant 42 messaging services), and little interoperability between services 43 based on these protocols has been achieved. This specification 44 defines common semantics and data formats for presence to facilitate 45 the creation of gateways between presence services. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Abstract Presence Service . . . . . . . . . . . . . . . . . 4 52 3.1 Overview of the Presence Service . . . . . . . . . . . . . . 4 53 3.2 Identification of PRESENTITIES and WATCHERS . . . . . . . . 6 54 3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 7 55 3.3 Format of Presence Information . . . . . . . . . . . . . . . 7 56 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 7 57 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 7 58 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 8 59 3.4.3 Subscribe Operation (with Zero Duration) . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 62 5.1 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 10 63 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 65 A. PRES URI IANA Registration Template . . . . . . . . . . . . 11 66 A.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . 11 67 A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 12 68 A.3 Character encoding considerations . . . . . . . . . . . . . 12 69 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 12 70 A.5 Applications and/or protocols which use this URI scheme 71 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 A.6 Interoperability considerations . . . . . . . . . . . . . . 12 73 A.7 Security considerations . . . . . . . . . . . . . . . . . . 12 74 A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 12 75 A.9 Person & email address to contact for further information . 13 76 A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 13 77 A.11 Applications and/or protocols which use this URI scheme 78 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 13 80 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 13 81 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 13 82 Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Informative References . . . . . . . . . . . . . . . . . . . 11 84 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Presence is defined in RFC2778 [5]. Today, numerous presence 90 protocols are in use (largely as components of commercial instant 91 messaging services), and little interoperability between services 92 based on these protocols has been achieved. This specification 93 defines semantics and data formats for common services of presence to 94 facilitate the creation of gateways between presence services: a 95 common profile for presence (CPP). 97 Service behavior is described abstractly in terms of operations 98 invoked between the consumer and provider of a service. Accordingly, 99 each presence service must specify how this behavior is mapped onto 100 its own protocol interactions. The choice of strategy is a local 101 matter, providing that there is a clear relation between the abstract 102 behaviors of the service (as specified in this memo) and how it is 103 faithfully realized by a particular presence service. For example, 104 one strategy might transmit presence information as key/value pairs, 105 another might use a compact binary representation, and a third might 106 use nested containers. 108 The parameters for each operation are defined using an abstract 109 syntax. Although the syntax specifies the range of possible data 110 values, each presence service must specify how well-formed instances 111 of the abstract representation are encoded as a concrete series of 112 bits. 114 In order to provide a means for the preservation of end-to-end 115 features (especially security) to pass through presence 116 interoperability gateways, this specification also provides 117 recommendations for presence document formats that could be employed 118 by presence protocols. 120 2. Terminology 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in RFC2119 [1] and indicate requirement levels for 126 compliant implementations. 128 This memos makes use of the vocabulary defined in RFC2778 [5]. Terms 129 such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in the 130 same meaning as defined therein. 132 The term 'gateway' used in this draft denotes a network element 133 responsible for interworking between diverse presence protocols. 134 Although the presence protocols themselves are diverse, under the 135 model used in this document these protocols can carry a common 136 payload that is relayed by the gateway. Whether these interworking 137 intermediaries should be called 'gateways' or 'relays' is therefore 138 somewhat debatable; for the purposes of this document, they are 139 called 'CPP gateways'. 141 The term 'presence service' also derives from RFC2778, but its 142 meaning changes slightly due to the existence of gateways in the CPP 143 model. When a client sends a operation to a presence service, that 144 service might either be an endpoint or an intermediary such as a CPP 145 gateway - in fact, the client should not have to be aware which it is 146 addressing, as responses from either will appear the same. 148 This document defines operations and attributes of an abstract 149 presence protocol. In order for a compliant protocol to interface 150 with a presence gateway, it must support all of the operations 151 described in this document (i.e. the presence protocol must have 152 some message or capability that provides the function described by 153 all given operations). Similarly, the attributes defined for these 154 operations must correspond to information available in the presence 155 protocol in order for the protocol to interface with gateways defined 156 by this specification. Note that these attributes provide only the 157 minimum possible information that needs to be specified for 158 interoperability - the functions in a presence protocol that 159 correspond to the operations described in this document can contain 160 additional information that will not be mapped by CPP. 162 3. Abstract Presence Service 164 3.1 Overview of the Presence Service 166 When an application wants to subscriber to the presence information 167 associated with a PRESENTITY (in order to receive periodic 168 notifications of presence information), it invokes the subscribe 169 operation, e.g., 171 +-------+ +-------+ 172 | | | | 173 | appl. | -- subscribe ----> | pres. | 174 | | | svc. | 175 +-------+ +-------+ 177 The subscribe operation has the following attributes: watcher, 178 target, duration, SubscriptID and TransID. The 'watcher' and 179 'target' identify the WATCHER and PRESENTITY, respectively, using the 180 identifiers described in Section 3.2. The duration specifies the 181 maximum number of seconds that the SUBSCRIPTION should be active 182 (which may be zero, in which case this is a one-time request for 183 presence information). The SubscriptID creates a reference to the 184 SUBSCRIPTION that is used when unsubscribing. The TransID is a 185 unique identifier used to correlate the subscribe operation with a 186 response operation. Gateways should be capable of handling TransIDs 187 and SubscriptIDs up to 40 bytes in length. 189 Upon receiving a subscribe operation, the service immediately 190 responds by invoking the response operation containing the same 191 TransID, e.g., 193 +-------+ +-------+ 194 | | | | 195 | appl. | <----- response -- | pres. | 196 | | | svc. | 197 +-------+ +-------+ 199 The response operation has the following attributes: status, TransID, 200 and duration. 'status' indicates whether the subscribe operation has 201 succeeded or failed. The TransID of the response operation 202 corresponds to the TransID of the subscription operation to which it 203 is responding. The 'duration' attribute specifies the number of 204 seconds for which the subscription will be active (which may differ 205 from the value requested in the subscribe operation). 207 If the response operation indicates success, the service immediately 208 invokes the notify operation to communicate the presence information 209 to the WATCHER, e.g., 211 +-------+ +-------+ 212 | | | | 213 | appl. | <------- notify -- | pres. | 214 | | | svc. | 215 +-------+ +-------+ 217 The notify operation has the following attributes: watcher, target, 218 and TransID. The values of 'watcher' and 'target' are identical to 219 those given in the subscribe operation that triggered this notify 220 operation. The TransID is a unique identifier for this notification. 222 The notify operation also has content, namely PRESENCE INFORMATION. 223 Content details are specified in in Section 3.3. 225 If the duration parameter is non-zero, then for up to the specified 226 duration, the service invokes the notify operation whenever there are 227 any changes to the PRESENTITY's presence information. Otherwise, 228 exactly one notify operation is invoked, achieving a one-time poll of 229 the presence information. Regardless, there is no application 230 response to the notify operation (i.e., the application does not 231 invoke a response operation when a notify operation occurs) defined 232 in CPP. 234 The application may prematurely cancel a subscription by re-invoking 235 the subscribe operation (as described above) with a duration of 0 and 236 the same SubscriptID as the original subscribe operation , e.g., 238 +-------+ +-------+ 239 | | | | 240 | appl. | -- subscribe 0 --> | pres. | 241 | | | svc. | 242 +-------+ +-------+ 244 Note that a notify operation will be invoked when a subscription is 245 prematurely canceled in this fashion; this notification may be 246 discarded by the watcher. 248 The service immediately responds by invoking the response operation 249 containing the same TransID; e.g., 251 +-------+ +-------+ 252 | | | | 253 | appl. | <----- response -- | pres. | 254 | | | svc. | 255 +-------+ +-------+ 257 Note that this specification assumes that CPP-compliant presence 258 protocols provide reliable message delivery; there are no 259 application-layer message delivery assurance provisions in this 260 specification. 262 3.2 Identification of PRESENTITIES and WATCHERS 264 A PRESENTITY is specified using the PRES URI scheme, which is further 265 described in Appendix A. An example would be: 266 "pres:fred@example.com" 268 WATCHERs identify themselves in the same manner as PRESENTITIES; that 269 is, with a pres URI. 271 3.2.1 Address Resolution 273 A presence service client determines the next hop to forward an 274 operation to by resolving the domain name portion of the service 275 destination. Compliant implementations SHOULD follow the guidelines 276 for dereferencing URIs given in [2]. 278 3.3 Format of Presence Information 280 This specification defines an abstract interoperability mechanism for 281 presence protocols; the message content definition given here 282 pertains to semantics rather than syntax. However, some important 283 properties for interoperability can only be provided if a common end- 284 to-end format for presence is employed by the interoperating presence 285 protocols, especially with respect to security. In order to maintain 286 end-to-end security properties, applications that send notification 287 operations through a CPP gateway MUST support the format defined in 288 PIDF [4]. Applications MAY support other content formats. 290 CPP gateways MUST be capable of relaying the body of a notification 291 operation between supported presence protocols without needing to 292 modify or inspect the content. 294 3.4 The Presence Service 296 An implementation of the service must maintain information about both 297 presence information and continual operations (like periodic 298 notification) in persistent storage. 300 Note that the subscription-identifier attribute used by the subscribe 301 operation is potentially long-lived. Accordingly, the values 302 generated for this parameter should be unique across a significant 303 duration of time. The SubscriptID parameter should be intrinsically 304 globally unique over time, not merely unique among operations sent to 305 or from a particular WATCHER and PRESENTITY. 307 3.4.1 The Subscribe Operation 309 When an application wants to subscribe to the presence information 310 associated with a PRESENTITY, it invokes the subscribe operation. 312 When the service is informed of the subscribe operation, it performs 313 these steps: 315 1. If the watcher or target parameter does not refer to a valid 316 PRESENTITY, a response operation having status "failure" is 317 invoked. 319 2. If access control does not permit the application to request this 320 operation, a response operation having status "failure" is 321 invoked. 323 3. If the duration parameter is non-zero, and if the watcher and 324 target parameters refer to an in-progress subscribe operation for 325 the application, a response operation having status "failure" is 326 invoked. 328 4. Otherwise, if the service is able to successfully deliver the 329 message: 331 A response operation having status "success" is immediately 332 invoked. (If the service chooses a different duration for the 333 subscription then it conveys this information in the response 334 operation.) 336 A notify operation, corresponding to the target's presence 337 information, is immediately invoked for the watcher. 339 For up to the amount of time indicated by the duration 340 parameter of the notify operation (measured from the time that 341 the subscribe operation was received), if the target's 342 presence information changes, and if access control allows, a 343 notify operation is invoked for the watcher. 345 Note that if the duration parameter is zero-valued, then the 346 subscribe operation is making a one-time poll of the presence 347 information. Accordingly, the final step above (continued 348 notifications for the duration of the subscription) does not occur. 350 When the service invokes a response operation as a result of this 351 processing, the transID parameter is identical to the value found in 352 the subscribe operation invoked by the application. 354 3.4.2 The Notify Operation 356 The service invokes the notify operation whenever the presence 357 information associated with a PRESENTITY changes and there are 358 subscribers requesting notifications for that PRESENTITY. 360 There is no application response to the notify operation. 362 3.4.3 Subscribe Operation (with Zero Duration) 364 When an application wants to terminate a subscription, it issues a 365 SUBSCRIBE 0 with the SubscriptID of an existing subscription. Note 366 that an notify operation will be invoked by the presentity when a 367 subscription is canceled in this fashion; this notification can be 368 discarded by the watcher. There is no independent UNSUBSCRIBE 369 operation. 371 When an application wants to directly request presence information to 372 be supplied immediately without initiating any persistent 373 subscription, it issues a SUBSCRIBE 0 with a new SubscriptID. There 374 is no independent FETCH operation. 376 4. Security Considerations 378 Detailed security considerations for presence protocols given in 379 RFC2779 (in particular, requirements are given in sections 5.1 380 through 5.3 with some motivating discussion in 8.2). 382 CPP defines an interoperability function that is employed by gateways 383 between presence protocols. CPP gateways MUST be compliant with the 384 minimum security requirements of the presence protocols with which 385 they interface. 387 The introduction of gateways to the security model of presence in 388 RFC2779 also introduces some new risks. End-to-end security 389 properties (especially confidentiality and integrity) between 390 presentities and watchers that interface through a CPP gateway can 391 only be provided if a common presence format (such as the format 392 described in [4]) is supported by the protocols interfacing with the 393 CPP gateway. 395 When end-to-end security is required, the notify operation MUST use 396 PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with 397 encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS 398 SignedData). 400 The S/MIME algorithms are set by CMS [9]. The AES [10] algorithm 401 should be preferred, as it is expected that AES best suits the 402 capabilities of many platforms. However, an IETF specificationfor 403 this is still incomplete as of the time of this writing. 405 When PRES URIs are placed in presence protocols, they convey the 406 identity of the sender and/or the recipient. In some cases, 407 anonymous messaging may be desired. Such a capability is beyond the 408 scope of this specification. 410 5. IANA Considerations 412 The IANA assigns the "pres" URI scheme. 414 5.1 The PRES URI Scheme 416 The Presence (PRES) URI scheme designates an Internet resource, 417 namely a PRESENTITY or WATCHER. 419 The syntax of a PRES URI is given in Appendix A. 421 6. Contributors 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 Authors' Addresses 479 Dave Crocker 480 Brandenburg InternetWorking 481 675 Spruce Drive 482 Sunnyvale, CA 94086 483 US 485 Phone: +1 408/246-8253 486 EMail: dcrocker@brandenburg.com 488 Jon Peterson 489 NeuStar, Inc. 490 1800 Sutter St 491 Suite 570 492 Concord, CA 94520 493 US 495 Phone: +1 925/363-8720 496 EMail: jon.peterson@neustar.biz 498 Appendix A. PRES URI IANA Registration Template 500 This section provides the information to register the pres: presence 501 URI . 503 A.1 URI scheme name 505 pres 507 A.2 URI scheme syntax 509 The syntax follows the existing mailto: URI syntax specified in 510 RFC2368. The ABNF is: 512 PRES-URI = "pres:" [ to ] [ headers ] 513 to = mailbox 514 headers = "?" header *( "&" header ) 515 header = hname "=" hvalue 516 hname = *urlc 517 hvalue = *urlc 519 A.3 Character encoding considerations 521 Representation of non-ASCII character sets in local-part strings is 522 limited to the standard methods provided as extensions to RFC2822" 523 [3]. 525 A.4 Intended usage 527 Use of the pres: URI follows closely usage of the mailto: URI. That 528 is, invocation of an PRES URI will cause the user's instant messaging 529 application to start, with destination address and message headers 530 fill-in according to the information supplied in the URI. 532 A.5 Applications and/or protocols which use this URI scheme name 534 It is anticipated that protocols compliant with RFC2779, and meeting 535 the interoperability requirements specified here, will make use of 536 this URI scheme name. 538 A.6 Interoperability considerations 540 The underlying exchange protocol used to send an instant message may 541 vary from service to service. Therefore complete, Internet-scale 542 interoperability cannot be guaranteed. However, a service conforming 543 to this specification permits gateways to achieve interoperability 544 sufficient to the requirements of RFC2779. 546 A.7 Security considerations 548 See Section 4. 550 A.8 Relevant publications 552 RFC2779, RFC2778 554 A.9 Person & email address to contact for further information 556 Jon Peterson [mailto:jon.peterson@neustar.biz] 558 A.10 Author/Change controller 560 This scheme is registered under the IETF tree. As such, IETF 561 maintains change control. 563 A.11 Applications and/or protocols which use this URI scheme name 565 Instant messaging service; presence service 567 Appendix B. Issues of Interest 569 This appendix briefly discusses issues that may be of interest when 570 designing an interoperation gateway. 572 B.1 Address Mapping 574 When mapping the service described in this memo, mappings that place 575 special information into the im: address local-part MUST use the 576 meta-syntax defined in RFC2846 [7]. 578 B.2 Source-Route Mapping 580 The easiest mapping technique is a form of source- routing and 581 usually is the least friendly to humans having to type the string. 582 Source-routing also has a history of operational problems. 584 Use of source-routing for exchanges between different services is by 585 a transformation that places the entire, original address string into 586 the im: address local part and names the gateway in the domain part. 588 For example, if the destination INSTANT INBOX is "pepp://example.com/ 589 fred", then, after performing the necessary character conversions, 590 the resulting mapping is: 592 im:pepp=example.com/fred@relay-domain 594 where "relay-domain" is derived from local configuration information. 596 Experience shows that it is vastly preferable to hide this mapping 597 from end-users - if possible, the underlying software should perform 598 the mapping automatically. 600 Appendix C. Acknowledgments 602 The authors would like to acknowledge John Ramsdell for his comments, 603 suggestions and enthusiasm. Thanks to Derek Atkins for editorial 604 fixes. 606 Full Copyright Statement 608 Copyright (C) The Internet Society (2003). All Rights Reserved. 610 This document and translations of it may be copied and furnished to 611 others, and derivative works that comment on or otherwise explain it 612 or assist in its implementation may be prepared, copied, published 613 and distributed, in whole or in part, without restriction of any 614 kind, provided that the above copyright notice and this paragraph are 615 included on all such copies and derivative works. However, this 616 document itself may not be modified in any way, such as by removing 617 the copyright notice or references to the Internet Society or other 618 Internet organizations, except as needed for the purpose of 619 developing Internet standards in which case the procedures for 620 copyrights defined in the Internet Standards process must be 621 followed, or as required to translate it into languages other than 622 English. 624 The limited permissions granted above are perpetual and will not be 625 revoked by the Internet Society or its successors or assigns. 627 This document and the information contained herein is provided on an 628 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 629 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 630 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 631 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 632 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 634 Acknowledgement 636 Funding for the RFC Editor function is currently provided by the 637 Internet Society.