idnits 2.17.1 draft-ietf-stox-im-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2014) is 3717 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 (-11) exists of draft-ietf-stox-chat-04 == Outdated reference: A later version (-11) exists of draft-ietf-stox-core-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0071' == Outdated reference: A later version (-11) exists of draft-ietf-stox-groupchat-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft 4 Intended status: Standards Track A. Houri 5 Expires: July 27, 2014 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 January 23, 2014 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging 12 draft-ietf-stox-im-07 14 Abstract 16 This document defines a bidirectional protocol mapping for the 17 exchange of single instant messages between the Session Initiation 18 Protocol (SIP) and the Extensible Messaging and Presence Protocol 19 (XMPP). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 27, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Internationalization Considerations . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 In order to help ensure interworking between instant messaging (IM) 70 systems that conform to the instant messaging / presence requirements 71 [RFC2779], it is important to clearly define protocol mappings 72 between such systems. Within the IETF, work has proceeded on two 73 instant messaging technologies: 75 o Various extensions to the Session Initiation Protocol ([RFC3261]) 76 for instant messaging, in particular the MESSAGE method extension 77 [RFC3428] 79 o The Extensible Messaging and Presence Protocol (XMPP), which 80 consists of a formalization of the core XML streaming protocols 81 developed originally by the Jabber open-source community; the 82 relevant specifications are [RFC6120] for the XML streaming layer 83 and [RFC6121] for basic presence and instant messaging extensions 85 One approach to helping ensure interworking between these protocols 86 is to map each protocol to the abstract semantics described in 87 [RFC3860]; that is the approach taken by 88 [I-D.ietf-simple-cpim-mapping] and [RFC3922]. By contrast, the 89 approach taken in this document is to directly map semantics from one 90 protocol to another (i.e., from SIP/SIMPLE to XMPP and vice-versa). 92 Both XMPP and IM-capable SIP systems enable entities to exchange 93 "instant messages". The term "instant message" usually refers to a 94 message sent between two entities for delivery in close to real time 95 (rather than a message that is stored and forwarded to the intended 96 recipient upon request). This document covers single messages only 97 (sometimes called "pager-mode" messaging), since they form the lowest 98 common denominator for IM. Separate documents cover one-to-one chat 99 sessions [I-D.ietf-stox-chat] and multi-party groupchat 100 [I-D.ietf-stox-groupchat]. 102 The architectural assumptions underlying such direct mappings are 103 provided in [I-D.ietf-stox-core], including mapping of addresses and 104 error conditions. The mappings specified in this document cover 105 basic instant messaging functionality, i.e., the exchange of a single 106 instant message between a SIP user and an XMPP user in either 107 direction. Mapping of more advanced functionality is out of scope 108 for this document, but other documents in this "series" cover such 109 topics. 111 2. Terminology 113 A number of terms used here are explained in [RFC3261], [RFC3428], 114 [RFC6120], and [RFC6121]. 116 Continuing the tradition of Shakespearean examples in XMPP 117 documentation, the actors in this document are an XMPP user 118 and a SIP user . 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 3. XMPP to SIP 127 As described in [RFC6121], a single instant message is an XML 128 stanza of type "normal" sent over an XML stream (since 129 "normal" is the default for the 'type' attribute of the 130 stanza, the attribute is often omitted). In this document we will 131 assume that such a message is sent from an XMPP client to an XMPP 132 server over an XML stream negotiated between the client and the 133 server, and that the client is controlled by a human user (this is a 134 simplifying assumption introduced for explanatory purposes only; the 135 XMPP sender could be an automated client, a component such as a 136 workflow application, a server, etc.). 138 When Juliet wants to send an instant message to Romeo, she interacts 139 with her XMPP client, which generates an XMPP stanza. The 140 syntax of the stanza, including required and optional 141 elements and attributes, is defined in [RFC6121] (for single instant 142 messages, the value of the 'to' address SHOULD be a "bare JID" of the 143 form "localpart@domainpart"). The following is an example of such a 144 stanza: 146 Example 1: XMPP user sends message: 148 | 150 | Art thou not Romeo, and a Montague? 151 | 153 Upon receiving such a message stanza, the XMPP server needs to 154 determine the identity of the domainpart in the 'to' address, which 155 it does by following the procedures explained in Section 5 of 156 [I-D.ietf-stox-core]. Here we assume that the XMPP server has 157 determined the domain is serviced by an IM-capable SIP server, that 158 it contains or has available to it an XMPP-SIP gateway or connection 159 manager (which enables it to speak natively to IM-capable SIP 160 servers), and that it hands off the message stanza to the XMPP-SIP 161 gateway. 163 The XMPP-SIP gateway is then responsible for translating the XMPP 164 message stanza into a SIP MESSAGE request from the XMPP user to the 165 SIP user: 167 Example 2: XMPP user sends message (SIP transformation): 169 | MESSAGE sip:romeo@example.net SIP/2.0 170 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 171 | Max-Forwards: 70 172 | To: sip:romeo@example.net 173 | From: ;tag=12345 174 | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA 175 | CSeq: 1 MESSAGE 176 | Content-Type: text/plain 177 | Content-Length: 35 178 | 179 | Art thou not Romeo, and a Montague? 181 The destination SIP server is responsible for delivering the message 182 to the intended recipient, and the recipient is responsible for 183 generating a response (e.g., 200 OK). 185 Example 3: SIP user agent indicates receipt of message: 187 | SIP/2.0 200 OK 188 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 189 | From: sip:romeo@example.net;tag=vwxyz 190 | To: sip:juliet@example.com;tag=12345 191 | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA 192 | CSeq: 1 MESSAGE 193 | Content-Length: 0 195 As described in [RFC3428], a downstream proxy could fork a MESSAGE 196 request, but it would return only one 200 OK to the gateway. 198 Informational Note: This document does not specify handling of the 199 200 OK by the XMPP-SIP gateway (e.g., to enable message 200 acknowledgements). See [I-D.ietf-stox-chat] for a mapping of 201 message acknowledgements in the context of one-to-one chat 202 sessions. 204 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the 205 following table. (Mappings for several aspects not mentioned here 206 are specified in [I-D.ietf-stox-chat].) 208 Table 1: Message syntax mapping from XMPP to SIP 210 +-----------------------------+--------------------------+ 211 | XMPP Element or Attribute | SIP Header or Contents | 212 +-----------------------------+--------------------------+ 213 | | body of MESSAGE | 214 | | Subject | 215 | | Call-ID | 216 | from | From (1) | 217 | id | (no mapping) | 218 | to | To or Request-URI | 219 | type | (no mapping) (2) | 220 | xml:lang | Content-Language | 221 +-----------------------------+--------------------------+ 223 1. As shown in the foregoing example and described in 224 [I-D.ietf-stox-core], the XMPP-SISIP gateway SHOULD map the full 225 JID (localpart@domainpart/resourcepart) of the XMPP sender to the 226 SIP From header and include the resourcepart as the GRUU portion 227 [RFC5627] of the SIP URI. 229 2. Because there is no SIP header field that matches the meaning of 230 the XMPP message 'type' values ("normal", "chat", "groupchat", 231 "headline", "error"), no general mapping is possible here. 233 4. SIP to XMPP 235 As described in [RFC3428], a single instant message is a SIP MESSAGE 236 request sent from a SIP user agent to an intended recipient who is 237 most generally referenced by an Instant Message URI of the form 238 but who might be referenced by a SIP or SIPS URI of 239 the form or . Here again we 240 introduce the simplifying assumption that the user agent is 241 controlled by a human user, whom we shall dub . 243 When Romeo wants to send an instant message to Juliet, he interacts 244 with his SIP user agent, which generates a SIP MESSAGE request. The 245 syntax of the MESSAGE request is defined in [RFC3428]. The following 246 is an example of such a request: 248 Example 4: SIP user sends message: 250 | MESSAGE sip:juliet@example.com SIP/2.0 251 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 252 | Max-Forwards: 70 253 | To: sip:juliet@example.com 254 | From: sip:romeo@example.net;tag=vwxyz 255 | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E 256 | CSeq: 1 MESSAGE 257 | Content-Type: text/plain 258 | Content-Length: 44 259 | 260 | Neither, fair saint, if either thee dislike. 262 Section 5 of [RFC3428] stipulates that a SIP User Agent presented 263 with an im: URI should resolve it to a sip: or sips: URI. Therefore 264 we assume that the Request-URI of a request received by an IM-capable 265 SIP-XMPP gateway will contain a sip: or sips: URI. The SIP server 266 needs to determine the identity of the domain portion of the Request- 267 URI or To header, which it does by following the procedures explained 268 in Section 5 of [I-D.ietf-stox-core]. Here we assume that the SIP 269 server has determined that the domain is serviced by an XMPP server, 270 that it contains or has available to it an IM-aware SIP-to-XMPP 271 gateway or connection manager (which enables it to speak natively to 272 XMPP servers), and that it hands off the message to the gateway. 274 The SIP-to-XMPP gateway is then responsible for translating the 275 request into an XMPP message stanza from the SIP user to the XMPP 276 user and returning a SIP "200 OK" message to the sender: 278 Example 5: SIP user sends message (XMPP transformation): 280 | 282 | Neither, fair saint, if either thee dislike. 283 | 285 Note that the stanza handling rules specified in [RFC6121] allow the 286 receiving XMPP server to deliver a message stanza whose 'to' address 287 is a bare JID ("localpart@domainpart") to multiple connected devices. 288 This is similar to the "forking" of messages in SIP. 290 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the 291 following table. (Mappings for several aspects not mentioned here 292 are specified in [I-D.ietf-stox-chat].) 294 Table 2: Message syntax mapping from SIP to XMPP 296 +--------------------------+-----------------------------+ 297 | SIP Header or Contents | XMPP Element or Attribute | 298 +--------------------------+-----------------------------+ 299 | Call-ID | | 300 | Content-Language | xml:lang | 301 | CSeq | (no mapping) | 302 | From | from (1) | 303 | Subject | | 304 | Request-URI or To | to | 305 | body of MESSAGE | | 306 +--------------------------+-----------------------------+ 308 1. As shown in the foregoing example and described in 309 [I-D.ietf-stox-core], if the IM-capable SIP-XMPP gateway has 310 information about the GRUU [RFC5627] of the particular endpoint 311 that sent the SIP message then it SHOULD map the sender's address 312 to a full JID (localpart@domainpart/resourcepart) in the 'from' 313 attribute of the XMPP stanza and include the GRUU as the 314 resourcepart. 316 When transforming SIP pager-mode messages, an IM-capable SIP-XMPP 317 gateway SHOULD specify no XMPP 'type' attribute or, equivalently, a 318 'type' attribute whose value is "normal" [RFC6121]. 320 See Section 5 of this document about the handling of SIP message 321 bodies that contain content types other than plain text. 323 5. Content Types 324 SIP requests of type MESSAGE are allowed to contain essentially any 325 content type. The recommended procedures for SIP-to-XMPP gateways to 326 use in handling these content types are as follows. 328 An IM-aware SIP-to-XMPP gateway MUST process SIP messages that 329 contain message bodies of type "text/plain" and MUST encapsulate such 330 message bodies as the XML character data of the XMPP element. 332 An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that 333 contain message bodies of type "text/html"; if so, a gateway MUST 334 transform the "text/html" content into XHTML content that conforms to 335 the XHTML-IM Integration Set specified in [XEP-0071]. 337 Although an IM-aware SIP-to-XMPP gateway MAY process SIP messages 338 that contain message bodies of types other than "text/plain" and 339 "text/html", the handling of such content types is a matter of 340 implementation. 342 6. Internationalization Considerations 344 Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode 345 characters [UNICODE] within messages, and signalling of the language 346 for a particular message (in XMPP via the 'xml:lang' attribute and in 347 SIP via the Content-Language header). Several examples follow, using 348 the "XML Notation" for Unicode characters outside the ASCII range 349 described in [RFC3987]. 351 Example 6: SIP user sends message: 353 | MESSAGE sip:juliet@example.com SIP/2.0 354 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 355 | Max-Forwards: 70 356 | To: sip:juliet@example.com 357 | From: sip:romeo@example.net;tag=vwxyz 358 | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E 359 | CSeq: 1 MESSAGE 360 | Content-Type: text/plain 361 | Content-Length: 45 362 | Content-Language: cs 363 | 364 | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, 365 | nenavid쎭얡-li jedno nebo druh쎩. 367 Example 7: SIP user sends message (XMPP transformation): 369 | 372 | 373 | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, 374 | nenavid쎭얡-li jedno nebo druh쎩. 375 | 376 | 378 7. IANA Considerations 380 This document requests no actions of IANA. 382 8. Security Considerations 384 Detailed security considerations for instant messaging protocols are 385 given in [RFC2779], for SIP-based instant messaging in [RFC3428] (see 386 also [RFC3261]), and for XMPP-based instant messaging in [RFC6121] 387 (see also [RFC6120]). The security considerations provided in 388 [I-D.ietf-stox-core] also apply. 390 This document specifies methods for exchanging instant messages 391 through a gateway that translates between SIP and XMPP. Such a 392 gateway MUST be compliant with the minimum security requirements of 393 the instant messaging protocols for which it translates (i.e., SIP 394 and XMPP). The addition of gateways to the security model of instant 395 messaging specified in [RFC2779] introduces some new risks. In 396 particular, end-to-end security properties (especially 397 confidentiality and integrity) between instant messaging user agents 398 that interface through an IM-capable SIP-XMPP gateway can be provided 399 only if common formats are supported. Specification of those common 400 formats is out of scope for this document, although it is preferred 401 to use [RFC3862] for instant messages. 403 9. References 405 9.1. Normative References 407 [I-D.ietf-stox-chat] 408 Saint-Andre, P., Loreto, S., Gavita, E., and N. Hossain, 409 "Interworking between the Session Initiation Protocol 410 (SIP) and the Extensible Messaging and Presence Protocol 411 (XMPP): One-to-One Text Chat Sessions", draft-ietf-stox- 412 chat-04 (work in progress), December 2013. 414 [I-D.ietf-stox-core] 415 Saint-Andre, P., Houri, A., and J. Hildebrand, 416 "Interworking between the Session Initiation Protocol 417 (SIP) and the Extensible Messaging and Presence Protocol 418 (XMPP): Core", draft-ietf-stox-core-09 (work in progress), 419 December 2013. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 425 A., Peterson, J., Sparks, R., Handley, M., and E. 426 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 427 June 2002. 429 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 430 and D. Gurle, "Session Initiation Protocol (SIP) Extension 431 for Instant Messaging", RFC 3428, December 2002. 433 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 434 Agent URIs (GRUUs) in the Session Initiation Protocol 435 (SIP)", RFC 5627, October 2009. 437 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 438 Protocol (XMPP): Core", RFC 6120, March 2011. 440 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 441 Protocol (XMPP): Instant Messaging and Presence", RFC 442 6121, March 2011. 444 [XEP-0071] 445 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, November 2012. 447 9.2. Informative References 449 [I-D.ietf-simple-cpim-mapping] 450 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 451 Presence and Instant Messaging", draft-ietf-simple-cpim- 452 mapping-01 (work in progress), June 2002. 454 [I-D.ietf-stox-groupchat] 455 Saint-Andre, P., Corretge, S., and S. Loreto, 456 "Interworking between the Session Initiation Protocol 457 (SIP) and the Extensible Messaging and Presence Protocol 458 (XMPP): Groupchat", draft-ietf-stox-groupchat-02 (work in 459 progress), December 2013. 461 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 462 / Presence Protocol Requirements", RFC 2779, February 463 2000. 465 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 466 10646", STD 63, RFC 3629, November 2003. 468 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 469 (CPIM)", RFC 3860, August 2004. 471 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 472 Messaging (CPIM): Message Format", RFC 3862, August 2004. 474 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 475 Presence Protocol (XMPP) to Common Presence and Instant 476 Messaging (CPIM)", RFC 3922, October 2004. 478 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 479 Identifiers (IRIs)", RFC 3987, January 2005. 481 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 482 6.2", 2012, 483 . 485 Appendix A. Acknowledgements 487 The authors wish to thank the following individuals for their 488 feedback: Mary Barnes, Dave Cridland, Adrian Georgescu, Christer 489 Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul Kyzivat, 490 Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe. 492 The authors gratefully acknowledge the assistance of Markus Isomaki 493 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 494 as the sponsoring Area Director. 496 Authors' Addresses 498 Peter Saint-Andre 500 Email: ietf@stpeter.im 501 Avshalom Houri 502 IBM 503 Rorberg Building, Pekris 3 504 Rehovot 76123 505 Israel 507 Email: avshalom@il.ibm.com 509 Joe Hildebrand 510 Cisco Systems, Inc. 511 1899 Wynkoop Street, Suite 600 512 Denver, CO 80202 513 USA 515 Email: jhildebr@cisco.com