idnits 2.17.1 draft-ietf-impp-pres-04.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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 14, 2003) is 7561 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 470, 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) Summary: 5 errors (**), 0 flaws (~~), 7 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: February 12, 2004 August 14, 2003 6 Common Profile for Presence (CPP) 7 draft-ietf-impp-pres-04 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 February 12, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 At the time this document was written, numerous presence protocols 39 are in use (largely as components of commercial instant messaging 40 services), and little interoperability between services based on 41 these protocols has been achieved. This specification defines common 42 semantics and data formats for presence to facilitate the creation of 43 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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 12 65 A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 13 73 A.9 Person & email address to contact for further information . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14 83 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 Presence is defined in RFC2778 [5]. At the time this document was 88 written, numerous presence protocols are in use (largely as 89 components of commercial instant messaging services), and little 90 interoperability between services based on these protocols has been 91 achieved. This specification defines semantics and data formats for 92 common services of presence to facilitate the creation of gateways 93 between presence services: a 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. Implementations MAY use AES as an 401 encryption algorithm, but are REQUIRED to support only the baseline 402 algorithms mandated by S/MIME and CMS. 404 When PRES URIs are used in presence protocols, they convey the 405 identity of watchers and/or presentities. Certificates that are used 406 for S/MIME presence operations SHOULD, for the purposes of reference 407 integrity, contain a subjectAltName field containing the PRES URI of 408 their subject. Note that such certificates may also contain other 409 identifiers, including those specific to particular presence 410 protocols. In order to further facilitate interoperability of secure 411 presence services through CPP gateways, users and service providers 412 are encouraged to employ trust anchors for certificates that are 413 widely accepted rather than trust anchors specific to any particular 414 presence service or provider. 416 In some cases, anonymous presence services may be desired. Such a 417 capability is beyond the scope of this specification. 419 5. IANA Considerations 421 The IANA assigns the "pres" URI scheme. 423 5.1 The PRES URI Scheme 425 The Presence (PRES) URI scheme designates an Internet resource, 426 namely a PRESENTITY or WATCHER. 428 The syntax of a PRES URI is given in Appendix A. 430 6. Contributors 432 Dave Crocker edited earlier versions of this document. 434 The following individuals made substantial textual contributions to 435 this document: 437 Athanassios Diacakis (thanos.diacakis@openwave.com) 439 Florencio Mazzoldi (flo@networkprojects.com) 441 Christian Huitema (huitema@microsoft.com) 443 Graham Klyne (gk@ninebynine.org) 445 Jonathan Rosenberg (jdrosen@dynamicsoft.com) 447 Robert Sparks (rsparks@dynamicsoft.com) 449 Hiroyasu Sugano (suga@flab.fujitsu.co.jp) 451 Normative References 453 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 454 levels", RFC 2119, March 1997. 456 [2] Crocker, D. and J. Peterson, "Address resolution for Instant 457 Messaging and Presence", draft-ietf-impp-srv-02 (work in 458 progress), February 2003. 460 [3] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 461 2001. 463 [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 464 J. Peterson, "CPIM Presence Information Data Format", draft- 465 ietf-impp-cpim-pidf-07 (work in progress), January 2003. 467 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 468 Instant Messaging", RFC 2778, February 2000. 470 [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 471 Presence Protocol Requirements", RFC 2779, February 2000. 473 [7] Allocchio, C., "GSTN Address Element Extensions in Email 474 Services", RFC 2846, June 2000. 476 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 477 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 479 [9] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 480 2002. 482 Informative References 484 [10] Schaad, J., "Use of the Advanced Encryption Standard (AES) 485 Encryption Algorithm and in Cryptographic Message Syntax 486 (CMS)", RFC 3565, July 2003. 488 Author's Address 490 Jon Peterson 491 NeuStar, Inc. 492 1800 Sutter St 493 Suite 570 494 Concord, CA 94520 495 US 497 Phone: +1 925/363-8720 498 EMail: jon.peterson@neustar.biz 500 Appendix A. PRES URI IANA Registration Template 502 This section provides the information to register the pres: presence 503 URI . 505 A.1 URI scheme name 507 pres 509 A.2 URI scheme syntax 511 The syntax follows the existing mailto: URI syntax specified in 512 RFC2368. The ABNF is: 514 PRES-URI = "pres:" [ to ] [ headers ] 515 to = mailbox 516 headers = "?" header *( "&" header ) 517 header = hname "=" hvalue 518 hname = *urlc 519 hvalue = *urlc 521 A.3 Character encoding considerations 523 Representation of non-ASCII character sets in local-part strings is 524 limited to the standard methods provided as extensions to RFC2822" 525 [3]. 527 A.4 Intended usage 529 Use of the pres: URI follows closely usage of the mailto: URI. That 530 is, invocation of an PRES URI will cause the user's instant messaging 531 application to start, with destination address and message headers 532 fill-in according to the information supplied in the URI. 534 A.5 Applications and/or protocols which use this URI scheme name 536 It is anticipated that protocols compliant with RFC2779, and meeting 537 the interoperability requirements specified here, will make use of 538 this URI scheme name. 540 A.6 Interoperability considerations 542 The underlying exchange protocol used to send an instant message may 543 vary from service to service. Therefore complete, Internet-scale 544 interoperability cannot be guaranteed. However, a service conforming 545 to this specification permits gateways to achieve interoperability 546 sufficient to the requirements of RFC2779. 548 A.7 Security considerations 550 See Section 4. 552 A.8 Relevant publications 554 RFC2779, RFC2778 556 A.9 Person & email address to contact for further information 558 Jon Peterson [mailto:jon.peterson@neustar.biz] 560 A.10 Author/Change controller 562 This scheme is registered under the IETF tree. As such, IETF 563 maintains change control. 565 A.11 Applications and/or protocols which use this URI scheme name 567 Instant messaging service; presence service 569 Appendix B. Issues of Interest 571 This appendix briefly discusses issues that may be of interest when 572 designing an interoperation gateway. 574 B.1 Address Mapping 576 When mapping the service described in this memo, mappings that place 577 special information into the im: address local-part MUST use the 578 meta-syntax defined in RFC2846 [7]. 580 B.2 Source-Route Mapping 582 The easiest mapping technique is a form of source- routing and 583 usually is the least friendly to humans having to type the string. 584 Source-routing also has a history of operational problems. 586 Use of source-routing for exchanges between different services is by 587 a transformation that places the entire, original address string into 588 the im: address local part and names the gateway in the domain part. 590 For example, if the destination INSTANT INBOX is "pepp://example.com/ 591 fred", then, after performing the necessary character conversions, 592 the resulting mapping is: 594 im:pepp=example.com/fred@relay-domain 596 where "relay-domain" is derived from local configuration information. 598 Experience shows that it is vastly preferable to hide this mapping 599 from end-users - if possible, the underlying software should perform 600 the mapping automatically. 602 Appendix C. Acknowledgments 604 The authors would like to acknowledge John Ramsdell for his comments, 605 suggestions and enthusiasm. Thanks to Derek Atkins for editorial 606 fixes. 608 Full Copyright Statement 610 Copyright (C) The Internet Society (2003). All Rights Reserved. 612 This document and translations of it may be copied and furnished to 613 others, and derivative works that comment on or otherwise explain it 614 or assist in its implementation may be prepared, copied, published 615 and distributed, in whole or in part, without restriction of any 616 kind, provided that the above copyright notice and this paragraph are 617 included on all such copies and derivative works. However, this 618 document itself may not be modified in any way, such as by removing 619 the copyright notice or references to the Internet Society or other 620 Internet organizations, except as needed for the purpose of 621 developing Internet standards in which case the procedures for 622 copyrights defined in the Internet Standards process must be 623 followed, or as required to translate it into languages other than 624 English. 626 The limited permissions granted above are perpetual and will not be 627 revoked by the Internet Society or its successors or assigns. 629 This document and the information contained herein is provided on an 630 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 631 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 632 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 633 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 634 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Acknowledgement 638 Funding for the RFC Editor function is currently provided by the 639 Internet Society.