idnits 2.17.1 draft-ietf-simple-cpim-mapping-01.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '...rst, the gateway MUST determine if the...' RFC 2119 keyword, line 142: '...est, the gateway MUST treat it as a re...' RFC 2119 keyword, line 143: '...ubscriptions. the gateway MUST reject...' RFC 2119 keyword, line 161: '...the contrary, this value SHOULD be one...' RFC 2119 keyword, line 182: '...ful or indeterminant, the gateway MUST...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 408 has weird spacing: '... Sparks dyn...' -- 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 26, 2002) is 7968 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) == Outdated reference: A later version (-03) exists of draft-ietf-impp-cpim-02 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-07 == Outdated reference: A later version (-07) exists of draft-ietf-sip-message-05 ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft J. Rosenberg 4 Expires: December 25, 2002 dynamicsoft 5 June 26, 2002 7 CPIM Mapping of SIMPLE Presence and Instant Messaging 8 draft-ietf-simple-cpim-mapping-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 25, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 The SIMPLE work group has defined a SIP events package for 40 distribution of presence information. It has also proposed a MESSAGE 41 extension for the transport of instant messages. This document 42 describes how those mechanisms map to the abstract CPIM service, in 43 order to interoperate with other CPIM compliant presence and instant 44 messaging services. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. The CPIM Abstract Gateway Service . . . . . . . . . . . . . . 3 50 3. Mapping SIMPLE Presence to CPIM . . . . . . . . . . . . . . . 4 51 3.1 Mapping SUBSCRIBE reqests to CPIM . . . . . . . . . . . . . . 5 52 3.2 Mapping CPIM subscriptions to SIP . . . . . . . . . . . . . . 7 53 4. CPIM Mapping for Instant Messages . . . . . . . . . . . . . . 9 54 4.1 Mapping SIP MESSAGE requests to CPIM . . . . . . . . . . . . . 9 55 4.2 Mapping CPIM operations to SIP . . . . . . . . . . . . . . . . 9 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 62 1. Introduction 64 Common Presence and Instant Messaging (CPIM) [2] describes the 65 semantics of an abstract presence and instant messaging service. 66 Concrete service protocols, such as SIMPLE, that conform to the CPIM 67 should be able to interoperate with each other using CPIM compliant 68 gateways. 70 The SIMPLE work group designed SIP [1] based protocols for the 71 distribution of instant messages and presence documents. Presence 72 [3] may be distributed using a SIP event [5] package. Instant 73 Messages may be transferred using the MESSAGE [4] method extension to 74 SIP. 76 This document describes how the SIMPLE presence and instant message 77 mechanisms map to the abstract CPIM service. 79 2. The CPIM Abstract Gateway Service 81 A SIMPLE based service may interoperate with other CPIM compliant 82 services through the use of a gateway. This document describes a 83 gateway to an abstract CPIM service. In any actual implementation, 84 this gateway would convert SIMPLE to some other concrete protocol. 85 As long as that protocol also maps to CPIM, the gateway semantics 86 will be the same. 88 For the purposes of this document, we show the CPIM abstract gateway 89 as handling both presence and instant messages. In a concrete 90 implementation this may or not be true--a single gateway might handle 91 both, or there might be a separate gateway for each service. 93 --------------------------------------------------------------------- 95 +-------------+ 96 | | 97 | SIP to CPIM | 98 | Conversion | 99 | | 100 SIMPLE | | CPIM Service 101 <-------------->| | <---------------> 102 | | 103 | | 104 | | 105 | | 106 | | 107 | | 108 +-------------+ 110 Figure 1: CPIM Abstract Gateway 112 --------------------------------------------------------------------- 114 3. Mapping SIMPLE Presence to CPIM 116 This section defines how a SIP SUBSCRIBE and NOTIFY requests may be 117 converted to CPIM, and how CPIM messages are converted to SIP for 118 presence. SIP to CPIM conversion occurs when a SIP system sends a 119 SUBSCRIBE request that contains a pres URL or SIP URL that 120 corresponds to a user in a domain that runs a different presence 121 protocol. CPIM to SIP involves the case where a user in a different 122 protocol domain generates a subscription that is destined for a user 123 in a SIP domain. 125 Note that the process defined below requires that the gateway store 126 both transaction and subscription state. The transaction state is 127 needed to map the SIP transaction identifiers to the CPIM transID 128 value. Subscription state is needed to store the SIP dialog 129 information associated with the subscription. 131 From the SIP perspective, the CPIM gateway is an endpoint, that is, 132 it is the terminating point for the SIP transactions and dialogs. 133 The gateway can be thought of as a b2bua, except that the opposite 134 side implements the abstract CPIM service (or some concrete CPIM 135 compliant service.) 137 3.1 Mapping SUBSCRIBE reqests to CPIM 139 The SUBSCRIBE process begins when the CPIM gateway receives a SIP 140 SUBSCRIBE requests. First, the gateway MUST determine if the request 141 is an initial request or a mid-dialog request. If it is a mid-dialog 142 request, the gateway MUST treat it as a refresh. Note that since 143 CPIM does not allow duplicate subscriptions. the gateway MUST reject 144 any new SUBSCRIBE request that would result in watcher and target 145 identies that match an existing subscription with a 486 response. 147 Otherwise, the The gateway generates a corresponding CPIM 148 subscription request message in the following fashion: 150 o Copy the watcher identity from the SIP From header.If the From 151 header contains a SIP URL, the gateway converts it to a presence 152 URL. This mapping is based on the local policy or the gateway. 154 o Copy the Request-URI from the SUBSCRIBE request to the target 155 value of the CPIM message. This URL may also require conversion 156 to the "pres" scheme. 158 o Copy the Expires header from the SUBSCRIBE request to the duration 159 parameter in the CPIM message. If the SUBSCRIBE request does not 160 contain an Expires header, choose a value based on local policy. 161 If there is no policy to the contrary, this value SHOULD be one 162 hour. 164 o Construct the transID parameter by determining the SIP transaction 165 identity as described in RFC3261 [1] and choosing a transID value 166 that maps uniquely to the SIP transaction identity. How this 167 mapping is achieved is a matter of gateway local policy. 169 The CPIM service then a "success", "failure", or "indeterminate" 170 response. If the CPIM gateway can determine immediately (that is, 171 quickly enough to avoid retransmissions on the part of the requestor) 172 that a subscription is sucessful, it returns a 200 response. If it 173 can immediately determine the request is unsuccessful, it generates a 174 603 response. If the result is indeterminate, or cannot be 175 determined immediately, the gateway sends a 202 response. 177 In the event of a successful response, the gateway copies the 178 duration value into an Expires header of the SIP response. The 179 gateway adds a Contact header to the SIP response which contains the 180 target identity. 182 If the subscription was successful or indeterminant, the gateway MUST 183 establish subscription state. This state maps the SIP dialog to the 184 combination of CPIM watcher and target identities. 186 When the CPIM system generates a notification request, the gateway 187 first checks that the target and watcher values match an existing 188 subscription. If no match exists, the gateway ignores the request. 189 If a match does exist, the gateway constructs and sends a SIP NOTIFY 190 request according standard procedures for mid-dialog requests. In 191 additon, the gateway populates the request in the following manner: 193 o Copy the watcher identity to the From header. 195 o Copy the target identity to the To header. (The Request-URI comes 196 from the Contact header in the original subscribe.) 198 o Copies the presence information into the body of the NOTIFY 199 request. 201 CPIM has no concept of responses to notifications, so for the most 202 part the gateway simply consumes responses to SIP NOTIFY requests. 203 However, if such a response indicates a failure of the NOTIFY 204 request, the gateway SHOULD cease forwarding future NOTIFY requests 205 from the CPIM service for the associated subscription. If the NOTIFY 206 response was a 481, then the gateway MUST cease sending notifies for 207 the associated subscription. If the gateway ceases forwarding of 208 notifications on a subscription, it SHOULD initiate an unsubscribe 209 request to the CPIM service. 211 The gateway handles subscription request refreshes simularly to 212 initial subscription requests, except that the gateway will already 213 have dialog state stored for the subscription. 215 The gateway handles an unsubscribe request, that is, a SIP SUBSCRIBE 216 request with an Expires of zero, in exactly the same manner as a 217 subscription refresh. This will result in a CPIM subscribe request 218 with a duration or zero, which results in the removal of the 219 subscription. 221 The CPIM response to the unsubscribe attempt is either success or 222 failure. In the case of success, the gateway returns a SIP 2XX class 223 response. In the case of failure, the gateway returns a 6XX class 224 response. The responses are constructed in the same manner as above. 225 The gateway should remove any subscription state, if present. 227 3.2 Mapping CPIM subscriptions to SIP 229 The gateway maps CPIM subscriptions to SIP when a CPIM subscription 230 request arrives at the gateway. 232 The gateway coverts the subscription request into a SIP SUBSCRIBE 233 request. The gateway determines if this request is for an existing 234 subsciption by comparing the target and watcher to those of existing 235 subscriptions. If the there is a match, the request is for the 236 refresh of an existing subscription. 238 For a new subscription, the gateway constructs a SUBSCRIBE request in 239 the following manner: 241 o Set the From header to the watcher value of the CPIM request. 242 This may require mapping of presence URIs to SIP URIs, based on 243 the local policy of the gateway. 245 o Set the To header and the Request-URI to the target value of the 246 CPIM request. This may require mapping of presence URIs to SIP 247 URIs, based on the local policy of the gateway. 249 o Set the Expires header to the duration value from the CPIM 250 request. 252 The gateway then sends the SUBSCRIBE request following normal SIP 253 rules. 255 For a subscription refresh, the gateway determines the subscription 256 dialog that matches the target and watcher in the CPIM request. It 257 generates the SIP SUBSCRIBE request in much the same manner as for a 258 new subscription, except that it must follow the normal SIP rules for 259 a mid-dialog request. 261 When the gateway receives the SIP response, it constructs a response 262 to the CPIM system in the following manner: 264 o Copy the Expires header to the duration value. 266 o Determine the transID from the stored transaction state. 268 o For a 202 response, make the status "indeterminate." For any other 269 2XX class response, make the status "success." For any non-2XX 270 class final response, make the status "failure." 272 If the subscription was successful, the gateway MUST establish 273 subscription state. This state maps the SIP dialog identifying 274 information to the combination of CPIM watcher and target identities. 276 If the gateway receives an unsubscribe request from the CPIM service, 277 it checks whether the subscription state exists based on the target 278 and watcher value. If the subscription does exist, the gateway 279 constructs a SUBSCRIBE request as described above, but with an 280 Expires header of zero. If the subscription did not exist, the 281 gateway returns a failure response to the CPIM service. 283 When the gateway receives a SIP NOTIFY request, it first determines 284 if the request matches an existing dialog. If not, it returns a 481 285 response. If the request matches an existing subscription dialog, 286 the gateway constructs a CPIM notification request in the following 287 fashion: 289 o Set the watcher value to the Request-URI. 291 o Set the target to the URI in the From header. 293 o Generate a transID that maps uniquely to the SIP transaction. 295 The gateway then generates a 200 OK response to the NOTIFY request. 296 Note that the CPIM service does not send a response to a notification 297 request. The gateway SHOULD treat all notifies that match an 298 existing dialog as successful. 300 Note that a SIP NOTIFY can indicate the subscription has been 301 terminated, by the inclusing of a Subscription-State header value of 302 "terminated." CPIM has no similar concept. Therefore the gateway has 303 no mechanism by which it can inform the CPIM service that a 304 subscription has been terminated early. 306 If early termination occurs, the gateway MAY choose to simply drop 307 state for the subscription. It MAY generate a NOTIFY request 308 containing a presence body indicating that the current presence state 309 of the presentity is no longer known (the mechanism for which is out 310 of scope for this document). It MAY choose to generate a new SIP 311 SUBSCRIBE request. 313 4. CPIM Mapping for Instant Messages 315 This section describes how the gateway may map instant messages 316 between a SIP-based service and a CPIM service. The mapping of IMs 317 is much simpler than presence, due to the fact that IMs do not 318 initiate a SIP dialog. 320 4.1 Mapping SIP MESSAGE requests to CPIM 322 When the gateway receives a SIP MESSAGE request, it generates a CPIM 323 message operation in the following manner: 325 o Create the source identity based on the sender's credentials or 326 From header in the case of an unauthenticated message. However, 327 the gateway SHOULD authenticate the MESSAGE request. If the 328 request is authenticated, the source identity MUST be the 329 authenticated credentials. If the sender's identity is not 330 authenticated, then the gateway SHOULD indicate that fact in a 331 display-name or comment section of the source parameter. Note 332 that this may require converting the URL scheme from "sip:" to 333 "im:", based on the local policy of the gateway. 335 o Copy the Request-URI to the destination parameter. Note that this 336 may also require URL conversion. 338 o Generate a transID value, maintaining sufficient local transaction 339 state to associate the CPIM response with the SIP request. 341 o Copy the body from the SIP MESSAGE request into the body of the 342 CPIM message. If the body has a MIME type of message/cpim, it 343 MUST be sent unchanged, to allow for end-to-end encryption and 344 signatures of message/cpim bodies. Any other type MUST be 345 imbedded into a message/cpim body part. 347 If the CPIM service responds with a "success", the gateway SHOULD 348 generate a 200 response. If the CPIM service responds with 349 "failure", the gateway SHOULD return a 603 response. If the gateway 350 has a local policy to neither confirm or deny delivery of IMs, it MAY 351 return a 202 to all requests. If the gateway UAS cannot determine 352 the results of the message operation in a short enough time to avoid 353 a SIP transaction timeout, it MUST return a 202 accepted response. 355 4.2 Mapping CPIM operations to SIP 357 When a gateway maps a CPIM message operation to SIP, it generates a 358 SIP MESSAGE request according to the following procedure: 360 o Copy the destination identity to the Request-URI and the To 361 header, converting the URL schemes if required. 363 o Copy the CPIM body into the SIP body unchanged. 365 o Create the SIP dialog identifying information so that it uniquely 366 maps to transID. The method for this mapping is a matter of local 367 implementation. 369 o Establish local transaction state. 371 When the gateway receives a final response to the SIP request, it 372 generates the CPIM response in the following manner: 374 o If the response was a 202, set the status to "indeterminate". 376 o If the response was any other 2XX class response, set the status 377 to "success." 379 o If the response was any 4XX,5XX,or 6XX class response, set the 380 status to "failure." 382 o Determine the transID from local transaction state. 384 5. Security Considerations 386 End-to-end security concerns for instant messaging were a primary 387 driving force behind the creation of message/cpim. Application 388 designers needing end-to-end security should study that work 389 carefully. In all cases, gateways MUST NOT modify a message/cpim 390 body part in any way. 392 There are several cases in this document where a gateway determines 393 an IM source or watcher identity from a SIP message. While in some 394 cases, the From header is the only source of such information, the 395 From header is not the best choice. In general, gateways SHOULD 396 authenticate the sender's identity in some manner. The nature of 397 this authentication is beyond the scope of this document. If the 398 gateway authenticates the sender's identity, it MUST determine the 399 source or watcher from the authenticated credentials instead of the 400 From header. 402 6. Acknowledgments 404 The authors would like to thank the following people for their help 405 in the creation of this document. 407 Adam Roach dynamicsoft 408 Robert Sparks dynamicsoft 409 and 410 All authors of the SIMPLE presence and IM drafts 412 References 414 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 415 Protocol", RFC 3261, February 2002. 417 [2] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., 418 Rose, M., Rosenberg, J., Sparks, R. and H. Sugano, "A Common 419 Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-02 420 (work in progress), November 2001. 422 [3] Rosenberg, et al, J., "SIP Extensions for Presence", draft-ietf- 423 simple-presence-07 (work in progress), May 2002. 425 [4] Campbell, B. and J. Rosenberg, "SIP Extensions for Instant 426 Messaging", draft-ietf-sip-message-05 (work in progress), June 427 2002. 429 [5] Roach, A., "SIP-Specific Event Notification", RFC 3265, February 430 2002. 432 Authors' Addresses 434 Ben Campbell 435 dynamicsoft 436 5100 Tennyson Parkway 437 Suite 1200 438 Plano, TX 75024 440 EMail: bcampbell@dynamicsoft.com 441 Jonathan Rosenberg 442 dynamicsoft 443 72 Eagle Rock Avenue 444 First Floor 445 East Hanover, NJ 07936 447 EMail: jdrosen@dynamicsoft.com 449 Full Copyright Statement 451 Copyright (C) The Internet Society (2002). All Rights Reserved. 453 This document and translations of it may be copied and furnished to 454 others, and derivative works that comment on or otherwise explain it 455 or assist in its implementation may be prepared, copied, published 456 and distributed, in whole or in part, without restriction of any 457 kind, provided that the above copyright notice and this paragraph are 458 included on all such copies and derivative works. However, this 459 document itself may not be modified in any way, such as by removing 460 the copyright notice or references to the Internet Society or other 461 Internet organizations, except as needed for the purpose of 462 developing Internet standards in which case the procedures for 463 copyrights defined in the Internet Standards process must be 464 followed, or as required to translate it into languages other than 465 English. 467 The limited permissions granted above are perpetual and will not be 468 revoked by the Internet Society or its successors or assigns. 470 This document and the information contained herein is provided on an 471 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 472 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 473 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 474 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 475 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 Acknowledgement 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.