idnits 2.17.1 draft-miller-xmpp-cpim-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: o Access control MAY NOT permit the application to request this operation. -- 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 21, 2002) is 7972 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '3') -- No information found for draft-miller-jabber-xmpp-core - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-miller-jabber-xmpp-im - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2822 (ref. '7') (Obsoleted by RFC 5322) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Miller 3 Internet-Draft P. Saint-Andre 4 Expires: December 20, 2002 Jabber Software Foundation 5 T. Bamonti 6 Jabber, Inc. 7 June 21, 2002 9 XMPP CPIM Mapping 10 draft-miller-xmpp-cpim-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 20, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This document describes a mapping of the eXtensible Messaging and 42 Presence Protocol (XMPP) to the Common Presence and Instant Messaging 43 specification. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.3 Conventions Used in this Document . . . . . . . . . . . . 3 51 1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 3 52 1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 3 53 2. CPIM Gateway . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. CPIM Mapping for Instant Messages . . . . . . . . . . . . 5 55 3.1 Identification of INSTANT INBOXes . . . . . . . . . . . . 5 56 3.2 The Message Operation . . . . . . . . . . . . . . . . . . 5 57 3.2.1 Message Parameters . . . . . . . . . . . . . . . . . . . . 5 58 3.2.2 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2.3 Message Delivery . . . . . . . . . . . . . . . . . . . . . 6 60 4. CPIM Mapping for Presence . . . . . . . . . . . . . . . . 8 61 4.1 Identification of PRESENTITIES . . . . . . . . . . . . . . 8 62 4.2 The Presence Service . . . . . . . . . . . . . . . . . . . 8 63 4.2.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 8 64 4.2.1.1 Duration Parameter Considerations . . . . . . . . . . . . 9 65 4.2.1.2 Subscription Exceptions . . . . . . . . . . . . . . . . . 9 66 4.2.1.3 Completing the Subscribe Operation . . . . . . . . . . . . 10 67 4.2.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 10 68 4.2.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 11 69 4.2.4 The Fetch Operation . . . . . . . . . . . . . . . . . . . 12 70 5. Security Considerations . . . . . . . . . . . . . . . . . 14 71 References . . . . . . . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 73 Full Copyright Statement . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 1.1 Overview 79 Common Presence and Instant Messaging (CPIM) [1] describes an 80 abstract framework for interoperability of instant messaging and 81 presence systems compliant with RFC 2779 [2]. This document 82 describes how systems based on the eXtensible Messaging and Presence 83 Protocol (XMPP) map to the abstract CPIM model. 85 1.2 Terminology 87 This memo makes use of the vocabulary defined in RFC 2778 [3]. Terms 88 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE 89 SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same 90 meaning as defined therein. This memo also makes use of the 91 vocabulary defined in XMPP Core [4]. Terms such as ENTITY, JABBER 92 IDENTIFIER (JID), NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE 93 IDENTIFIER, MESSAGE ELEMENT, PRESENCE ELEMENT, and IQ ELEMENT are 94 used in the same meaning as defined therein. 96 1.3 Conventions Used in this Document 98 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 99 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in RFC 101 2119 [5]. 103 1.4 Discussion Venue 105 The authors welcome discussion and comments related to the topics 106 presented in this document, preferably on the "jabber- 107 ietf@jabber.org" mailing list (archives and subscription information 108 are available at http://www.jabber.org/cgi-bin/mailman/listinfo/ 109 jabber-ietf/). 111 1.5 Intellectual Property Notice 113 This document is in full compliance with all provisions of Section 10 114 of RFC 2026. Parts of this specification use the term "jabber" for 115 identifying URI schemes, namespaces, and other protocol syntax. 116 Jabber[tm] is a trademark of Jabber, Inc. If the IETF places this 117 document, or a successor document, on the standards track, then 118 Jabber, Inc. grants permission for use of the trademark "Jabber" in 119 association with that specification. 121 2. CPIM Gateway 123 A common method for achieving interoperability between two disparate 124 systems or services is through the use of a "gateway" that interprets 125 the protocols of each system and translates them into the protocols 126 of the other. CPIM defines the common method of agreement to be used 127 for interoperability of instant messaging and presence systems/ 128 services compliant with RFC 2779 [2]. This document describes the 129 manner in which an instant messaging and presence system based on 130 XMPP will interface to a gateway that supports the CPIM 131 specifications. As such, this document assumes no more about the 132 target instant messaging and presence system than that it also 133 complies with the abstract CPIM service definition. 135 +-------------+ +-------------+ +--------------+ 136 | | | | | | 137 | XMPP | | CPIM | | CPIM- | 138 | Service | <----> | Gateway | <----> | Compliant | 139 | | | | | Service | 140 +-------------+ +-------------+ +--------------+ 142 3. CPIM Mapping for Instant Messages 144 This section describes how a CPIM compliant gateway MAY map instant 145 messages between an XMPP service and a CPIM service. 147 3.1 Identification of INSTANT INBOXes 149 There is a one-to-one relationship between an XMPP ENTITY and a CPIM 150 INSTANT INBOX. This relationship is made possible using a JABBER 151 IDENTIFER (JID) and conforming to RFC 2822 [7] (e.g., "node@domain") 152 where the "node" part maps to an XMPP NODE IDENTIFIER and is 153 interpreted and assigned semantics only by the DOMAIN IDENTIFIER 154 specified in the "domain" part. 156 3.2 The Message Operation 158 3.2.1 Message Parameters 160 When an XMPP service sends or receives an INSTANT MESSAGE it uses the 161 XMPP MESSAGE ELEMENT. The XMPP MESSAGE ELEMENT maps to the CPIM 162 service as follows: 164 When sending messages from XMPP to CPIM: 166 o The XMPP "from" attribute (node@domain) maps to the CPIM "message 167 source" field (im:node@domain). The CPIM gateway SHOULD append 168 the "im:" Instant Messaging URI scheme to the front of the 169 address. 171 o The XMPP "to" attribute (node@domain) maps to the CPIM 172 "destination" field (im:node@domain). The CPIM gateway SHOULD 173 append the "im:" Instant Messaging URI scheme to the front of the 174 address. 176 o The XMPP "id" attribute maps to the CPIM "TransID" field. 178 o The XMPP element maps to the CPIM "message" field. 180 When sending messages from CPIM to XMPP: 182 o The CPIM "message source" field (im:node@domain) maps to the XMPP 183 "from" attribute (node@domain). The CPIM gateway SHOULD remove 184 the "im:" Instant Messaging URI scheme from the front of the 185 address. 187 o The CPIM "destination" field (im:node@domain) maps to the XMPP 188 "to" attribute (node@domain). The CPIM gateway SHOULD remove the 189 "im:" Instant Messaging URI scheme to the front of the address. 191 o The CPIM "TransID" field maps to the XMPP "id" attribute. 193 o The CPIM "message" field maps to the XMPP element. 195 3.2.2 Exceptions 197 During a message operation, an exception is encountered if: 199 o The source or destination does not refer to a valid INSTANT INBOX; 200 or 202 o Access control does not permit the application to request this 203 operation; or 205 o The service is unable to successfully deliver the message. 207 Exceptions between an XMPP service and a CPIM service are mapped as 208 follows: 210 o Messaging errors originating from XMPP to CPIM SHOULD translate to 211 a CPIM "response status" of failure. 213 o Messaging errors originating from CPIM to XMPP SHOULD translate to 214 an XMPP element of type code = 503 (Service Unavailable). 216 Since the CPIM service does not specify error codes to distinguish 217 between different error events, it is not possible to map context- 218 specific error information originating from the CPIM service back to 219 the XMPP service. However, it is expected that most real-world 220 instant messaging and presence service implementations will support 221 some level of contextual exception handling. In these cases, the 222 CPIM gateway would be designed in a fashion to map the contextual 223 error messages between interoperating systems. For the purpose of 224 this document, since all CPIM exceptions result in a generic status 225 of "failure", the associated mapping to the XMPP service SHOULD be to 226 the XMPP element of type code = 503 (Service Unavailable). 228 3.2.3 Message Delivery 230 By default, XMPP services operate on an "exception" basis. That is, 231 if an operation is successful, no status response is sent. If an 232 operation is unsuccessful, then an response is delivered. 233 This is by design to limit unnecessary network overhead. 235 When sending a message from CPIM to XMPP: 237 o If the XMPP service is able to successfully deliver the message, 238 no status response will be delivered. If no response is received 239 by the CPIM gateway (i.e., no error message is delivered) after 240 delivering a message to an XMPP service, then a CPIM gateway 241 response operation having status "success" SHOULD be sent to the 242 CPIM service. 244 o If the XMPP service is unable to successfully deliver the message, 245 an XMPP message will be sent to the CPIM gateway. This 246 will result in a response operation having status "failure" sent 247 to the CPIM service. The XMPP "id" attribute returned with the 248 error message will be identical to the "transID" value of the 249 originating CPIM message. The CPIM gateway will map the XMPP "id" 250 to the CPIM "transID" parameter for delivery of the error message 251 to the CPIM service. 253 When sending a message from XMPP to CPIM: 255 o If the CPIM service is able to successfully deliver the message, 256 the "success" response SHOULD be silently dropped. 258 o If the CPIM service is unable to successfully deliver the message, 259 a response status message of type "failure" will be generated by 260 the CPIM service. This SHOULD result in the CPIM gateway sending 261 an XMPP message of type code = 503 (Service Unavailable) 262 to the XMPP service. 264 4. CPIM Mapping for Presence 266 This section describes how a CPIM compliant gateway SHOULD map 267 presence information between an XMPP service and a CPIM service. 269 4.1 Identification of PRESENTITIES 271 There is a one-to-one relationship between an XMPP ENTITY and a CPIM 272 PRESENTITY using a JABBER IDENTIFER (JID) and conforming to RFC 2822 273 [7] (e.g., "node@domain") where the "node" part maps to an XMPP NODE 274 IDENTIFIER and is interpreted and assigned semantics only by the 275 DOMAIN IDENTIFIER specified in the "domain" part (e.g., 276 "node@domain"). 278 4.2 The Presence Service 280 4.2.1 The Subscribe Operation 282 This section describes how a "subscribe" operation will be performed 283 between an XMPP service and a CPIM service. 285 When an application wants to (periodically) receive the presence 286 information associated with a PRESENTITY, it invokes the subscribe 287 operation. 289 When an XMPP service performs a "subscribe" operation it uses the 290 XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM 291 service as follows: 293 When sending a subscription request from XMPP to CPIM: 295 o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher 296 parameter" field (pres:node@domain). The CPIM gateway SHOULD 297 append the "pres:" Presence URI scheme to the front of the 298 address. 300 o The XMPP "to" attribute (node@domain) maps to the CPIM "target 301 parameter" field (pres:node@domain). The CPIM gateway SHOULD 302 append the "pres:" Presence URI scheme to the front of the 303 address. 305 o There is no XMPP mapping for the CPIM "duration parameter". XMPP 306 subscriptions are active until they have been explicitly 307 "unsubscribed". See Duration Parameter Considerations (Section 308 4.2.1.1) below for further discussion regarding the "duration 309 parameter". 311 o The XMPP "id" attribute maps to the CPIM "TransID" field. 313 o The XMPP "subscribe" attribute maps to the CPIM "subscribe" 314 operation field. 316 When sending a subscription request from CPIM to XMPP: 318 o The CPIM "watcher parameter" field (pres:node@domain) maps to the 319 XMPP "from" attribute (node@domain). The CPIM gateway SHOULD 320 remove the "pres:" Presence URI scheme from the front of the 321 address. 323 o The CPIM "target parameter" field (im:node@domain) maps to the 324 XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove 325 the "pres:" Presence URI scheme to the front of the address. 327 o The CPIM "TransID" field maps to the XMPP "id" attribute. 329 o The CPIM "subscribe" operation field maps to the XMPP "subscribe" 330 attribute. 332 4.2.1.1 Duration Parameter Considerations 334 The XMPP service assumes a subscription to be active until it is 335 explicitly unsubscribed. Handling/mapping of a subscription 336 "duration parameter" will be highly dependent on the implementation 337 and requirements of the associated instant messaging and presence 338 system represented in this document by the CPIM service. Since there 339 are no explicit requirements for supporting a "duration parameter" 340 specified in either RFC 2778 [3] or RFC 2779 [2], this would be an 341 implementation/service specific consideration that falls outside of 342 the scope of this document. 344 4.2.1.2 Subscription Exceptions 346 During a "subscribe" operation, one of the following exceptions MAY 347 be encountered: 349 o The watcher or target parameter ("from" or "to") does not refer to 350 a valid PRESENTITY (or Jabber Identifier). 352 o Access control MAY NOT permit the application to request this 353 operation. 355 o There MAY be a pre-existing subscription or in-progress subscribe 356 operation between the watcher and the target entities. 358 o The target PRESENTITY denies the subscription request. 360 Exceptions between an XMPP service and a CPIM service are mapped as 361 follows: 363 o Messaging errors originating from XMPP to CPIM SHOULD translate to 364 a CPIM "response status" of failure. 366 o Messaging errors originating from CPIM to XMPP SHOULD translate to 367 an XMPP element of type code = 503 (Service Unavailable). 369 4.2.1.3 Completing the Subscribe Operation 371 If the subscribe request from the XMPP service to the CPIM service is 372 successful: 374 o The CPIM issues a "response status" = "success". This is mapped 375 to the XMPP PRESENCE ELEMENT attribute "type" = "subscribed" and 376 returned to the subscribing XMPP ENTITY. 378 o A notify operation, corresponding to the CPIM "target's" presence 379 information, is immediately invoked for the subscribing XMPP 380 ENTITY (see The Notify Operation (Section 4.2.2) below). 382 o Until the subscription is "unsubscribed", a notify operation is 383 invoked for the subscribing XMPP ENTITY every time the CPIM 384 "target's" presence information changes. 386 If the subscribe request from the CPIM service to the XMPP service is 387 successful: 389 o The XMPP service issues a PRESENCE ELEMENT response attribute 390 "type" = "subscribed". This is mapped to the CPIM "response 391 status" = "success" and returned to the subscribing CPIM 392 "watcher". 394 o A notify operation, corresponding to the XMPP ENTITY's presence 395 information, is immediately invoked for the subscribing CPIM 396 watcher (see The Notify Operation (Section 4.2.2) below). 398 o Until the subscription is "unsubscribed", a notify operation is 399 invoked for the subscribing CPIM watcher every time the XMPP 400 ENTITY's presence information changes. 402 4.2.2 The Notify Operation 404 This section describes how a "Notify" operation will be performed 405 between an XMPP service and a CPIM service. 407 A notify operation is invoked whenever the presence information 408 associated with an XMPP ENTITY or a CPIM PRESENTITY changes and there 409 are subscribers to that information. 411 When an XMPP service performs a "notify" operation indicating a 412 change in presence, it uses the XMPP PRESENCE ELEMENT. The XMPP 413 PRESENCE ELEMENT maps to the CPIM service as follows: 415 When sending a presence notification from XMPP to CPIM: 417 o The XMPP "from" attribute (node@domain) maps to the CPIM "target 418 parameter" field (pres:node@domain). The CPIM gateway SHOULD 419 append the "pres:" Presence URI scheme to the front of the 420 address. 422 o The XMPP "to" attribute (node@domain) maps to the CPIM "watcher 423 parameter" field (pres:node@domain). The CPIM gateway SHOULD 424 append the "pres:" Presence URI scheme to the front of the 425 address. 427 o The XMPP "id" attribute maps to the CPIM "TransID" field. 429 o The XMPP "type" attribute maps to the CPIM "presence information" 430 field. 432 When sending a presence notification from CPIM to XMPP: 434 o The CPIM "target parameter" field (pres:node@domain) maps to the 435 XMPP "from" attribute (node@domain). The CPIM gateway SHOULD 436 remove the "pres:" Presence URI scheme from the front of the 437 address. 439 o The CPIM "watcher parameter" field (im:node@domain) maps to the 440 XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove 441 the "pres:" Presence URI scheme from the front of the address. 443 o The CPIM "TransID" field maps to the XMPP "id" attribute. 445 o The CPIM "presence information" operation field maps to the XMPP 446 "type" attribute. 448 4.2.3 The Unsubscribe Operation 450 This section describes how an "unsubscribe" operation will be 451 performed between an XMPP service and a CPIM service. 453 When an application wants to cancel a subscription associated with a 454 PRESENTITY, it invokes the unsubscribe operation. 456 When an XMPP service performs an "unsubscribe" operation it uses the 457 XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM 458 service as follows: 460 When sending an unsubscribe command from XMPP to CPIM: 462 o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher 463 parameter" field (pres:node@domain). The CPIM gateway SHOULD 464 append the "pres:" Presence URI scheme to the front of the 465 address. 467 o The XMPP "to" attribute (node@domain) maps to the CPIM "target 468 parameter" field (pres:node@domain). The CPIM gateway SHOULD 469 append the "pres:" Presence URI scheme to the front of the 470 address. 472 o The XMPP "id" attribute maps to the CPIM "TransID" field. 474 o The XMPP "unsubscribe" attribute maps to the CPIM "unsubscribe" 475 field. 477 When sending an unsubscribe command from CPIM to XMPP: 479 o The CPIM "watcher parameter" field (pres:node@domain) maps to the 480 XMPP "from" attribute (node@domain). The CPIM gateway SHOULD 481 remove the "pres:" Presence URI scheme from the front of the 482 address. 484 o The CPIM "target parameter" field (im:node@domain) maps to the 485 XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove 486 the "pres:" Presence URI scheme from the front of the address. 488 o The CPIM "TransID" field maps to the XMPP "id" attribute. 490 o The CPIM "unsubscribe" operation field maps to the XMPP 491 "unsubscribe" attribute. 493 4.2.4 The Fetch Operation 495 This section describes how a "fetch" operation will be performed 496 between an XMPP service and a CPIM service. 498 The "fetch" operation is invoked when an application wants to 499 directly request presence information to be supplied immediately. 501 When an XMPP service performs a "fetch" operation it uses the XMPP 502 PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service 503 as follows: 505 When sending a fetch request from XMPP to CPIM: 507 o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher 508 parameter" field (pres:node@domain). The CPIM gateway SHOULD 509 append the "pres:" Presence URI scheme to the front of the 510 address. 512 o The XMPP "to" attribute (node@domain) maps to the CPIM "target 513 parameter" field (pres:node@domain). The CPIM gateway SHOULD 514 append the "pres:" Presence URI scheme to the front of the 515 address. 517 o The XMPP "id" attribute maps to the CPIM "TransID" field. 519 o The XMPP "probe" attribute maps to the CPIM "subscribe 0" 520 operation. 522 When sending a fetch request from CPIM to XMPP: 524 o The CPIM "watcher parameter" field (pres:node@domain) maps to the 525 XMPP "from" attribute (node@domain). The CPIM gateway SHOULD 526 remove the "pres:" Presence URI scheme from the front of the 527 address. 529 o The CPIM "target parameter" field (im:node@domain) maps to the 530 XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove 531 the "pres:" Presence URI scheme from the front of the address. 533 o The CPIM "TransID" field maps to the XMPP "id" attribute. 535 o The CPIM "subscribe 0" operation field maps to the XMPP "probe" 536 attribute. 538 5. Security Considerations 540 XMPP places a high priority on security and provides mechanisms for 541 securing client-to-server and server-to-server communications, 542 including payload encryption, digital signatures, client-server 543 authentication, and server-server authentication. Details regarding 544 XMPP security are provided in XMPP Core [4] and XMPP IM [6]. Details 545 regarding CPIM security considerations can be found in Common 546 Presence and Instant Messaging (CPIM) [1]. 548 References 550 [1] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., 551 Rosenberg, J., Sparks, R. and H. Sugano, "A Common Profile for 552 Instant Messaging (CPIM)", November 2001. 554 [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 555 Presence and Instant Messaging", RFC 2779, February 2000, 556 . 558 [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 559 Instant Messaging", RFC 2778, February 2000, . 562 [4] Miller, J. and P. Saint-Andre, "XMPP Core (draft-miller-jabber- 563 xmpp-core-00, work in progress)", June 2002. 565 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 566 Levels", BCP 14, RFC 2119, March 1997. 568 [6] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft- 569 miller-jabber-xmpp-im-00, work in progress)", June 2002. 571 [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 573 Authors' Addresses 575 Jeremie Miller 576 Jabber Software Foundation 577 1899 Wynkoop Street, Suite 600 578 Denver, CO 80202 579 US 581 EMail: jeremie@jabber.org 582 URI: http://www.jabber.org/ 584 Peter Saint-Andre 585 Jabber Software Foundation 586 1899 Wynkoop Street, Suite 600 587 Denver, CO 80202 588 US 590 EMail: stpeter@jabber.org 591 URI: http://www.jabber.org/ 592 T. Bamonti 593 Jabber, Inc. 594 1899 Wynkoop Street, Suite 600 595 Denver, CO 80202 596 US 598 EMail: tbamonti@jabber.com 599 URI: http://www.jabber.com/ 601 Full Copyright Statement 603 Copyright (C) The Internet Society (2002). All Rights Reserved. 605 This document and translations of it may be copied and furnished to 606 others, and derivative works that comment on or otherwise explain it 607 or assist in its implementation may be prepared, copied, published 608 and distributed, in whole or in part, without restriction of any 609 kind, provided that the above copyright notice and this paragraph are 610 included on all such copies and derivative works. However, this 611 document itself may not be modified in any way, such as by removing 612 the copyright notice or references to the Internet Society or other 613 Internet organizations, except as needed for the purpose of 614 developing Internet standards in which case the procedures for 615 copyrights defined in the Internet Standards process must be 616 followed, or as required to translate it into languages other than 617 English. 619 The limited permissions granted above are perpetual and will not be 620 revoked by the Internet Society or its successors or assigns. 622 This document and the information contained herein is provided on an 623 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 624 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 625 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 626 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 627 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 Acknowledgement 631 Funding for the RFC Editor function is currently provided by the 632 Internet Society.