idnits 2.17.1 draft-ietf-stox-im-08.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 (March 11, 2014) is 3698 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-06 -- 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 (~~), 3 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 &yet 4 Intended status: Standards Track A. Houri 5 Expires: September 12, 2014 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 March 11, 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-08 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 September 12, 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. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Internationalization Considerations . . . . . . . . . . . . . 8 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 In order to help ensure interworking between instant messaging (IM) 71 systems that conform to the instant messaging / presence requirements 72 [RFC2779], it is important to clearly define protocol mappings 73 between such systems. Within the IETF, work has proceeded on two 74 instant messaging technologies: 76 o Various extensions to the Session Initiation Protocol ([RFC3261]) 77 for instant messaging, in particular the MESSAGE method extension 78 [RFC3428] 80 o The Extensible Messaging and Presence Protocol (XMPP), which 81 consists of a formalization of the core XML streaming protocols 82 developed originally by the Jabber open-source community; the 83 relevant specifications are [RFC6120] for the XML streaming layer 84 and [RFC6121] for basic presence and instant messaging extensions 86 One approach to helping ensure interworking between these protocols 87 is to map each protocol to the abstract semantics described in 88 [RFC3860]; that is the approach taken by 89 [I-D.ietf-simple-cpim-mapping] and [RFC3922]. By contrast, the 90 approach taken in this document is to directly map semantics from one 91 protocol to another (i.e., from SIP/SIMPLE to XMPP and vice-versa). 93 Both XMPP and IM-capable SIP systems enable entities to exchange 94 "instant messages". The term "instant message" usually refers to a 95 message sent between two entities for delivery in close to real time 96 (rather than a message that is stored and forwarded to the intended 97 recipient upon request). This document covers single messages only 98 (sometimes called "pager-mode" messaging), since they form the lowest 99 common denominator for IM. Separate documents cover one-to-one chat 100 sessions [I-D.ietf-stox-chat] and multi-party groupchat 101 [I-D.ietf-stox-groupchat]. 103 The architectural assumptions underlying such direct mappings are 104 provided in [I-D.ietf-stox-core], including mapping of addresses and 105 error conditions. The mappings specified in this document cover 106 basic instant messaging functionality, i.e., the exchange of a single 107 instant message between a SIP user and an XMPP user in either 108 direction. Mapping of more advanced functionality is out of scope 109 for this document, but other documents in this "series" cover such 110 topics. 112 2. Intended Audience 114 The documents in this series are intended for use by software 115 developers who have an existing system based on one of these 116 technologies (e.g., SIP), and would like to enable communication from 117 that existing system to systems based on the other technology (e.g., 118 XMPP). We assume that readers are familiar with the core 119 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the 120 base document for this series [I-D.ietf-stox-core], and with the 121 following IM-related specifications: 123 o Session Initiation Protocol (SIP) Extension for Instant Messaging 124 [RFC3428] 126 o Extensible Messaging and Presence Protocol: Instant Messaging and 127 Presence [RFC6121] 129 3. Terminology 131 A number of terms used here are explained in [RFC3261], [RFC3428], 132 [RFC6120], and [RFC6121]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 4. XMPP to SIP 141 As described in [RFC6121], a single instant message is an XML 142 stanza of type "normal" sent over an XML stream (since 143 "normal" is the default for the 'type' attribute of the 144 stanza, the attribute is often omitted). In this document we will 145 assume that such a message is sent from an XMPP client to an XMPP 146 server over an XML stream negotiated between the client and the 147 server, and that the client is controlled by a human user (this is a 148 simplifying assumption introduced for explanatory purposes only; the 149 XMPP sender could be an automated client, a component such as a 150 workflow application, a server, etc.). 152 When Juliet wants to send an instant message to Romeo, she interacts 153 with her XMPP client, which generates an XMPP stanza. The 154 syntax of the stanza, including required and optional 155 elements and attributes, is defined in [RFC6121] (for single instant 156 messages, the value of the 'to' address SHOULD be a "bare JID" of the 157 form "localpart@domainpart"). The following is an example of such a 158 stanza: 160 Example 1: XMPP user sends message 162 | 164 | Art thou not Romeo, and a Montague? 165 | 167 Upon receiving such a message stanza, the XMPP server needs to 168 determine the identity of the domainpart in the 'to' address, which 169 it does by following the procedures explained in Section 5 of 170 [I-D.ietf-stox-core]. If the domain is a SIP domain, the XMPP server 171 will hand off the message stanza to an XMPP-to-SIP gateway or 172 connection manager that natively communicates with IM-aware SIP 173 servers. 175 The XMPP-SIP gateway is then responsible for translating the XMPP 176 message stanza into a SIP MESSAGE request from the XMPP user to the 177 SIP user: 179 Example 2: XMPP user sends message (SIP transformation) 181 | MESSAGE sip:romeo@example.net SIP/2.0 182 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 183 | Max-Forwards: 70 184 | To: sip:romeo@example.net 185 | From: ;tag=12345 186 | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA 187 | CSeq: 1 MESSAGE 188 | Content-Type: text/plain 189 | Content-Length: 35 190 | 191 | Art thou not Romeo, and a Montague? 192 The destination SIP server is responsible for delivering the message 193 to the intended recipient, and the recipient is responsible for 194 generating a response (e.g., 200 OK). 196 Example 3: SIP user agent indicates receipt of message 198 | SIP/2.0 200 OK 199 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 200 | From: sip:romeo@example.net;tag=vwxyz 201 | To: sip:juliet@example.com;tag=12345 202 | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA 203 | CSeq: 1 MESSAGE 204 | Content-Length: 0 206 As described in [RFC3428], a downstream proxy could fork a MESSAGE 207 request, but it would return only one 200 OK to the gateway. 209 Informational Note: This document does not specify handling of the 210 200 OK by the XMPP-SIP gateway (e.g., to enable message 211 acknowledgements). See [I-D.ietf-stox-chat] for a mapping of 212 message acknowledgements in the context of one-to-one chat 213 sessions. 215 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the 216 following table. (Mappings for several aspects not mentioned here 217 are specified in [I-D.ietf-stox-chat].) 219 Table 1: Message syntax mapping from XMPP to SIP 221 +-----------------------------+--------------------------+ 222 | XMPP Element or Attribute | SIP Header or Contents | 223 +-----------------------------+--------------------------+ 224 | | body of MESSAGE | 225 | | Subject | 226 | | Call-ID | 227 | from | From (1) | 228 | id | (no mapping) | 229 | to | To or Request-URI | 230 | type | (no mapping) (2) | 231 | xml:lang | Content-Language | 232 +-----------------------------+--------------------------+ 234 1. As shown in the foregoing example and described in 235 [I-D.ietf-stox-core], the XMPP-SIP gateway SHOULD map the full 236 JID (localpart@domainpart/resourcepart) of the XMPP sender to the 237 SIP From header and include the resourcepart as the GRUU portion 238 [RFC5627] of the SIP URI. 240 2. Because there is no SIP header field that matches the meaning of 241 the XMPP message 'type' values ("normal", "chat", "groupchat", 242 "headline", "error"), no general mapping is possible here. 244 5. SIP to XMPP 246 As described in [RFC3428], a single instant message is a SIP MESSAGE 247 request sent from a SIP user agent to an intended recipient who is 248 most generally referenced by an Instant Message URI of the form 249 but who might be referenced by a SIP or SIPS URI of 250 the form or . Here again we 251 introduce the simplifying assumption that the user agent is 252 controlled by a human user, whom we shall dub . 254 When Romeo wants to send an instant message to Juliet, he interacts 255 with his SIP user agent, which generates a SIP MESSAGE request. The 256 syntax of the MESSAGE request is defined in [RFC3428]. The following 257 is an example of such a request: 259 Example 4: SIP user sends message 261 | MESSAGE sip:juliet@example.com SIP/2.0 262 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 263 | Max-Forwards: 70 264 | To: sip:juliet@example.com 265 | From: sip:romeo@example.net;tag=vwxyz 266 | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E 267 | CSeq: 1 MESSAGE 268 | Content-Type: text/plain 269 | Content-Length: 44 270 | 271 | Neither, fair saint, if either thee dislike. 273 Section 5 of [RFC3428] stipulates that a SIP User Agent presented 274 with an im: URI should resolve it to a sip: or sips: URI. Therefore 275 we assume that the Request-URI of a request received by an IM-capable 276 SIP-XMPP gateway will contain a sip: or sips: URI. Upon receiving 277 the MESSAGE, the SIP (MSRP) server needs to determine the identity of 278 the domain portion of the Request-URI or To header, which it does by 279 following the procedures explained in Section 5 of 280 [I-D.ietf-stox-core]. If the domain is an XMPP domain, the SIP 281 server will hand off the MESSAGE to an associated SIP-XMPP gateway or 282 connection manager that natively communicates with XMPP servers. 284 The SIP-to-XMPP gateway is then responsible for translating the 285 request into an XMPP message stanza from the SIP user to the XMPP 286 user and returning a SIP "200 OK" message to the sender: 288 Example 5: SIP user sends message (XMPP transformation) 290 | 292 | Neither, fair saint, if either thee dislike. 293 | 295 Note that the stanza handling rules specified in [RFC6121] allow the 296 receiving XMPP server to deliver a message stanza whose 'to' address 297 is a bare JID ("localpart@domainpart") to multiple connected devices. 298 This is similar to the "forking" of messages in SIP. 300 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the 301 following table. (Mappings for several aspects not mentioned here 302 are specified in [I-D.ietf-stox-chat].) 304 Table 2: Message syntax mapping from SIP to XMPP 306 +--------------------------+-----------------------------+ 307 | SIP Header or Contents | XMPP Element or Attribute | 308 +--------------------------+-----------------------------+ 309 | Call-ID | | 310 | Content-Language | xml:lang | 311 | CSeq | (no mapping) | 312 | From | from (1) | 313 | Subject | | 314 | Request-URI or To | to | 315 | body of MESSAGE | | 316 +--------------------------+-----------------------------+ 318 1. As shown in the foregoing example and described in 319 [I-D.ietf-stox-core], if the IM-capable SIP-XMPP gateway has 320 information about the GRUU [RFC5627] of the particular endpoint 321 that sent the SIP message then it SHOULD map the sender's address 322 to a full JID (localpart@domainpart/resourcepart) in the 'from' 323 attribute of the XMPP stanza and include the GRUU as the 324 resourcepart. 326 When transforming SIP pager-mode messages, an IM-capable SIP-XMPP 327 gateway SHOULD specify no XMPP 'type' attribute or, equivalently, a 328 'type' attribute whose value is "normal" [RFC6121]. 330 See Section 6 of this document about the handling of SIP message 331 bodies that contain content types other than plain text. 333 6. Content Types 335 SIP requests of type MESSAGE are allowed to contain essentially any 336 content type. The recommended procedures for SIP-to-XMPP gateways to 337 use in handling these content types are as follows. 339 An IM-aware SIP-to-XMPP gateway MUST process SIP messages that 340 contain message bodies of type "text/plain" and MUST encapsulate such 341 message bodies as the XML character data of the XMPP element. 343 An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that 344 contain message bodies of type "text/html"; if so, a gateway MUST 345 transform the "text/html" content into XHTML content that conforms to 346 the XHTML-IM Integration Set specified in [XEP-0071]. 348 Although an IM-aware SIP-to-XMPP gateway MAY process SIP messages 349 that contain message bodies of types other than "text/plain" and 350 "text/html", the handling of such content types is a matter of 351 implementation. 353 7. Internationalization Considerations 355 Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode 356 characters [UNICODE] within messages, and signalling of the language 357 for a particular message (in XMPP via the 'xml:lang' attribute and in 358 SIP via the Content-Language header). Several examples follow, using 359 the "XML Notation" for Unicode characters outside the ASCII range 360 described in [RFC3987]. 362 Example 6: SIP user sends message 364 | MESSAGE sip:juliet@example.com SIP/2.0 365 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 366 | Max-Forwards: 70 367 | To: sip:juliet@example.com 368 | From: sip:romeo@example.net;tag=vwxyz 369 | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E 370 | CSeq: 1 MESSAGE 371 | Content-Type: text/plain 372 | Content-Length: 45 373 | Content-Language: cs 374 | 375 | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, 376 | nenavid쎭얡-li jedno nebo druh쎩. 378 Example 7: SIP user sends message (XMPP transformation) 380 | 383 | 384 | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, 385 | nenavid쎭얡-li jedno nebo druh쎩. 386 | 387 | 389 8. IANA Considerations 391 This document requests no actions of IANA. 393 9. Security Considerations 395 Detailed security considerations for instant messaging protocols are 396 given in [RFC2779], for SIP-based instant messaging in [RFC3428] (see 397 also [RFC3261]), and for XMPP-based instant messaging in [RFC6121] 398 (see also [RFC6120]). The security considerations provided in 399 [I-D.ietf-stox-core] also apply. 401 This document specifies methods for exchanging instant messages 402 through a gateway that translates between SIP and XMPP. Such a 403 gateway MUST be compliant with the minimum security requirements of 404 the instant messaging protocols for which it translates (i.e., SIP 405 and XMPP). The addition of gateways to the security model of instant 406 messaging specified in [RFC2779] introduces some new risks. In 407 particular, end-to-end security properties (especially 408 confidentiality and integrity) between instant messaging user agents 409 that interface through an IM-capable SIP-XMPP gateway can be provided 410 only if common formats are supported. Specification of those common 411 formats is out of scope for this document, although it is preferred 412 to use [RFC3862] for instant messages. 414 10. References 416 10.1. Normative References 418 [I-D.ietf-stox-chat] 419 Saint-Andre, P. and S. Loreto, "Interworking between the 420 Session Initiation Protocol (SIP) and the Extensible 421 Messaging and Presence Protocol (XMPP): One-to-One Text 422 Chat Sessions", draft-ietf-stox-chat-06 (work in 423 progress), March 2014. 425 [I-D.ietf-stox-core] 426 Saint-Andre, P., Houri, A., and J. Hildebrand, 427 "Interworking between the Session Initiation Protocol 428 (SIP) and the Extensible Messaging and Presence Protocol 429 (XMPP): Core", draft-ietf-stox-core-11 (work in progress), 430 February 2014. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 436 A., Peterson, J., Sparks, R., Handley, M., and E. 437 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 438 June 2002. 440 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 441 and D. Gurle, "Session Initiation Protocol (SIP) Extension 442 for Instant Messaging", RFC 3428, December 2002. 444 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 445 Agent URIs (GRUUs) in the Session Initiation Protocol 446 (SIP)", RFC 5627, October 2009. 448 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 449 Protocol (XMPP): Core", RFC 6120, March 2011. 451 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 452 Protocol (XMPP): Instant Messaging and Presence", RFC 453 6121, March 2011. 455 [XEP-0071] 456 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, November 2012. 458 10.2. Informative References 460 [I-D.ietf-simple-cpim-mapping] 461 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 462 Presence and Instant Messaging", draft-ietf-simple-cpim- 463 mapping-01 (work in progress), June 2002. 465 [I-D.ietf-stox-groupchat] 466 Saint-Andre, P., Corretge, S., and S. Loreto, 467 "Interworking between the Session Initiation Protocol 468 (SIP) and the Extensible Messaging and Presence Protocol 469 (XMPP): Groupchat", draft-ietf-stox-groupchat-02 (work in 470 progress), December 2013. 472 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 473 / Presence Protocol Requirements", RFC 2779, February 474 2000. 476 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 477 10646", STD 63, RFC 3629, November 2003. 479 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 480 (CPIM)", RFC 3860, August 2004. 482 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 483 Messaging (CPIM): Message Format", RFC 3862, August 2004. 485 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 486 Presence Protocol (XMPP) to Common Presence and Instant 487 Messaging (CPIM)", RFC 3922, October 2004. 489 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 490 Identifiers (IRIs)", RFC 3987, January 2005. 492 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 493 6.3", 2013, 494 . 496 Appendix A. Acknowledgements 498 The authors wish to thank the following individuals for their 499 feedback: Mary Barnes, Dave Cridland, Dave Crocker, Adrian Georgescu, 500 Christer Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul 501 Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe. 503 The authors gratefully acknowledge the assistance of Markus Isomaki 504 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 505 and Alissa Cooper as the sponsoring Area Directors. 507 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 508 employing him during his work on earlier versions of this document. 510 Authors' Addresses 512 Peter Saint-Andre 513 &yet 514 P.O. Box 787 515 Parker, CO 80134 516 USA 518 Email: ietf@stpeter.im 519 Avshalom Houri 520 IBM 521 Rorberg Building, Pekris 3 522 Rehovot 76123 523 Israel 525 Email: avshalom@il.ibm.com 527 Joe Hildebrand 528 Cisco Systems, Inc. 529 1899 Wynkoop Street, Suite 600 530 Denver, CO 80202 531 USA 533 Email: jhildebr@cisco.com