idnits 2.17.1 draft-ietf-stox-chat-01.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 (September 18, 2013) is 3871 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-core-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0085' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0184' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 Cisco Systems, Inc. 4 Intended status: Standards Track S. Loreto 5 Expires: March 22, 2014 E. Gavita 6 N. Hossain 7 Ericsson 8 September 18, 2013 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat 12 draft-ietf-stox-chat-01 14 Abstract 16 This document defines a bidirectional protocol mapping for the 17 exchange of instant messages in the context of a one-to-one chat 18 session between a user of the Session Initiation Protocol (SIP) and a 19 user of the Extensible Messaging and Presence Protocol (XMPP). 20 Specifically for SIP text chat, this document specifies a mapping to 21 the Message Session Relay Protocol (MSRP). 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 22, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Composing Events . . . . . . . . . . . . . . . . . . . . . . . 10 62 6. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 Both the Session Initiation Protocol [RFC3261] and the Extensible 74 Messaging and Presence Protocol [RFC6120] can be used for the purpose 75 of one-to-one text chat over the Internet. To ensure interworking 76 between these technologies, it is important to define bidirectional 77 protocol mappings. 79 The architectural assumptions underlying such protocol mappings are 80 provided in [I-D.ietf-stox-core], including mapping of addresses and 81 error conditions. This document specifies mappings for one-to-one 82 text chat sessions (sometimes called "session-mode" messaging); in 83 particular, this document specifies mappings between XMPP messages of 84 type "chat" and the Message Session Relay Protocol [RFC4975]. 85 Mappings for single instant messages and groupchat are provided in 86 separate documents. 88 The approach taken here is to directly map syntax and semantics from 89 one protocol to another. The mapping described herein depends on the 90 protocols defined in the following specifications: 92 o XMPP chat sessions using message stanzas of type "chat" are 93 specified in [RFC6121]. 94 o SIP-based chat sessions using the SIP INVITE and SEND request 95 types are specified in [RFC4975]. 97 In SIMPLE, a chat session is formally negotiated just as any other 98 session type is using SIP. By contrast, a one-to-one chat "session" 99 in XMPP is an informal construct and is not formally negotiated: a 100 user simply sends a message of type "chat" to a contact, the contact 101 then replies to the message, and the sum total of such messages 102 exchanged during a defined period of time is considered to be a chat 103 session. To overcome the disparity between these approaches, a 104 gateway that wishes to map between SIP and XMPP for one-to-one chat 105 sessions needs to maintain some additional state, as described below. 107 The discussion venue for this document is the mailing list of the 108 STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for 109 subscription information and discussion archives. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119]. 118 3. XMPP to MSRP 120 In XMPP, the "informal session" approach is to simply send someone a 121 of type "chat" without starting any session negotiation 122 ahead of time (as described in [RFC6121]). The XMPP "informal 123 session" approach maps very well into a SIP MESSAGE request, as 124 described in [I-D.ietf-stox-core]. However, the XMPP informal 125 session approach can also be mapped to MSRP if the XMPP-to-SIP 126 gateway maintains additional state. 128 The order of events is as follows. 130 XMPP User GW SIP User 131 | | | 132 |(F1) (XMPP) Chat message | | 133 |------------------------->| | 134 | |(F2) (SIP) INVITE | 135 | |------------------------->| 136 | |(F3) (SIP) 200 OK | 137 | |<-------------------------| 138 | |(F4) (SIP) ACK | 139 | |------------------------->| 140 | |(F5) (MSRP) SEND | 141 | |------------------------->| 142 | |(F6) (MSRP) A reply | 143 | |<-------------------------| 144 |(F7) (XMPP) A reply | | 145 |<-------------------------| | 146 | | | 147 . . . 148 . . . 149 . . . 150 | | | 151 | |(F8) (SIP) BYE | 152 | |<-------------------------| 153 | |(F9) (SIP) 200 OK | 154 | |------------------------->| 155 | | | 157 First the XMPP user would generate an XMPP chat message. 159 Example: (F1) Juliet sends an XMPP message 161 | 164 | 711609sa 165 | Art thou not Romeo, and a Montague? 166 | 168 The local SIP-to-XMPP gateway at the SIMPLE server would then 169 initiate an MSRP session with Romeo on Juliet's behalf (since there 170 is no reliable way for the SIMPLE server to determine if Romeo's user 171 agent supports MSRP, it simply needs to guess). 173 Example: (F2) Gateway starts a formal session on behalf of Juliet 175 | INVITE sip:romeo@example.net SIP/2.0 176 | To: 177 | From: 178 | Contact: ;gr=balcony 179 | Subject: Open chat with Juliet? 180 | Call-ID: 711609sa 181 | Content-Type: application/sdp 182 | 183 | c=IN IP4 x2s.example.com 184 | m=message 7654 TCP/MSRP * 185 | a=accept-types:text/plain 186 | a=lang:en 187 | a=lang:it 188 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 190 Here we assume that Romeo accepts the MSRP session request. 192 Example: (F3) Romeo accepts the request 194 | SIP/2.0 200 OK 195 | To: ;gr=balcony 196 | From: 197 | Contact: ;gr=orchard 198 | Call-ID: 711609sa 199 | Content-Type: application/sdp 200 | 201 | c=IN IP4 s2x.example.net 202 | m=message 12763 TCP/MSRP * 203 | a=accept-types:text/plain 204 | a=lang:it 205 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 206 The XMPP-to-SIP gateway then acknowledges the session acceptance on 207 behalf of Romeo. 209 Example: (F4) Gateway sends ACK to Romeo's UA 211 | ACK sip:juliet@example.com SIP/2.0 212 | To: ;gr=orchard 213 | From: 214 | Contact: ;gr=balcony 215 | Call-ID: 711609sa 217 The XMPP-to-SIP gateway then transforms the original XMPP chat 218 message into MSRP. 220 Example: (F5) Gateway transforms XMPP message to MSRP 222 | MSRP a786hjs2 SEND 223 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 224 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 225 | Message-ID: 87652491 226 | Byte-Range: 1-25/25 227 | Content-Type: text/plain 228 | 229 | Art thou not Romeo, and a Montague? 230 | -------a786hjs2$ 232 Romeo can then send a reply using his MSRP user agent. 234 Example: (F6) Romeo sends a reply 236 | MSRP a786hjs2 SEND 237 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 238 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 239 | Message-ID: 87652491 240 | Byte-Range: 1-25/25 241 | Failure-Report: no 242 | Content-Type: text/plain 243 | 244 | Neither, fair saint, if either thee dislike. 245 | -------a786hjs2$ 247 The SIP-to-XMPP gateway would then transform that message into 248 appropriate XMPP syntax for routing to the intended recipient. 250 Example: (F7) Gateway transforms MSRP message to XMPP 252 | 255 | 711609sa 256 | Neither, fair saint, if either thee dislike. 257 | 259 When the MSRP user wishes to end the chat session, the user's MSRP 260 client sends a SIP BYE. 262 Example: (F8) Romeo terminates the chat session 264 | BYE juliet@example.com sip: SIP/2.0 265 | Max-Forwards: 70 266 | From: ;tag=087js 267 | To: ;tag=786 268 | Call-ID: 711609sa 269 | Cseq: 1 BYE 270 | Content-Length: 0 272 The BYE is then acknowledged by the XMPP-to-SIP gateway. 274 Example: (F9) Gateway acknowledges termination 276 | SIP/2.0 200 OK 277 | From: ;tag=786 278 | To: ;tag=087js 279 | Call-ID: 711609sa 280 | CSeq: 1 BYE 281 | Content-Length: 0 283 4. MSRP to XMPP 285 When an MSRP client sends messages through a gateway to an XMPP 286 client that does not support formal sessinos, the order of events is 287 as follows. 289 SIP User GW XMPP User 290 | | | 291 |(F1)(SIP) INVITE | | 292 |------------------------>| | 293 |(F2)(SIP) 200 OK | | 294 |<------------------------| | 295 |(F3)(SIP) ACK | | 296 |------------------------>| | 297 |(F4)(MSRP) SEND | | 298 |------------------------>| | 299 | |(F5)(XMPP) A chat message | 300 | |------------------------->| 301 | |(F6)(XMPP) A reply | 302 | |<-------------------------| 303 | | | 304 |(F7)(MSRP) SEND | | 305 |<------------------------| | 306 | | | 307 . . . 308 . . . 309 . . . 310 | | | 311 |(F8)(SIP) BYE | | 312 |------------------------>| | 313 |(F9)(SIP) 200 OK | | 314 |<------------------------| | 315 | | | 317 Example: (F1) SIP user starts the session 319 | INVITE sip:juliet@example.com SIP/2.0 320 | To: 321 | From: 322 | Contact: ;gr=orchard 323 | Subject: Open chat with Romeo? 324 | Call-ID: 742507no 325 | Content-Type: application/sdp 326 | 327 | c=IN IP4 s2x.example.net 328 | m=message 7313 TCP/MSRP * 329 | a=accept-types:text/plain 330 | a=lang:en 331 | a=lang:it 332 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 333 Example: (F2) Gateway accepts session on Juliet's behalf 335 | SIP/2.0 200 OK 336 | To: ;gr=orchard 337 | From: 338 | Contact: ;gr=balcony 339 | Call-ID: 742507no 340 | Content-Type: application/sdp 341 | 342 | c=IN IP4 x2s.example.com 343 | m=message 8763 TCP/MSRP * 344 | a=accept-types:text/plain 345 | a=lang:it 346 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 348 Example: (F3) Romeo sends ACK 350 | ACK sip:juliet@example.com SIP/2.0 351 | To: ;gr=balcony 352 | From: 353 | Contact: ;gr=orchard 354 | Call-ID: 742507no 356 Example: (F4) Romeo sends a message 358 | MSRP ad49kswow SEND 359 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 360 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 361 | Message-ID: 44921zaqwsx 362 | Byte-Range: 1-32/32 363 | Failure-Report: no 364 | Content-Type: text/plain 365 | 366 | I take thee at thy word ... 367 | -------ad49kswow$ 369 Example: (F5) Romeo sends a message (XMPP translation) 371 | 374 | 742507no 375 | I take thee at thy word ... 376 | 377 Example: (F6) Juliet sends a reply 379 | 382 | 711609sa 383 | What man art thou ...? 384 | 386 Example: (F8) Gateway transforms XMPP message to MSRP 388 | MSRP a786hjs2 SEND 389 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 390 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 391 | Message-ID: 87652491 392 | Byte-Range: 1-25/25 393 | Failure-Report: no 394 | Content-Type: text/plain 395 | 396 | What man art thou ...? 397 | -------a786hjs2$ 399 Example: (F9) Romeo terminates the session 401 | BYE juliet@example.com sip: SIP/2.0 402 | Max-Forwards: 70 403 | To: ;gr=balcony 404 | From: 405 | Contact: ;gr=orchard 406 | Call-ID: 742507no 407 | Cseq: 1 BYE 408 | Content-Length: 0 410 Example: (F10) Gateway acknowledges the termination of the session on 411 behalf of XMPP user 413 | SIP/2.0 200 OK 414 | To: ;gr=balcony 415 | From: 416 | Contact: ;gr=orchard 417 | Call-ID: 742507no 418 | CSeq: 1 BYE 420 5. Composing Events 422 Both XMPP and MSRP enable a user agent to receive notifications when 423 a person's conversation partner is composing an instant message 424 within the context of a chat session. 426 For XMPP, the Chat State Notifications specification [XEP-0085] 427 defines five states: active, inactive, gone, composing, and paused. 428 Some of these states are related to the act of message composition 429 (composing, paused), whereas others are related to the sender's 430 involvement with the chat session (active, inactive, gone). 432 For MSRP (and SIMPLE in general), the Indication of Message 433 Composition for Instant Messaging specification [RFC3994] defines two 434 states: idle and active. Here the idle state indicates that the 435 sender is not actively composing a message, and the active state 436 indicates that the sender is indeed actively composing a message (the 437 sending user agent simply toggles between the two states, changing to 438 active if the user is actively composing a message and changing to 439 idle if the user is no longer actively composing a message). 441 Because the XEP-0085 states can represent information that is not 442 captured in RFC 3994, gateways can either (a) map only the composing- 443 related states or (b) map all the XEP-0085 states. 445 The following mappings are suggested. 447 Table 1: Mapping of SIMPLE isComposing events to XMPP chat states 449 +-------------------+--------------------+ 450 | isComposing Event | Chat State | 451 +-------------------+--------------------+ 452 | active | composing | 453 | idle | active | 454 +-------------------+--------------------+ 456 Table 2: Mapping of XMPP chat states to SIMPLE isComposing events 458 +-------------------+--------------------+ 459 | Chat State | isComposing Event | 460 +-------------------+--------------------+ 461 | active | idle | 462 | inactive | idle | 463 | gone | [none, see note] | 464 | composing | active | 465 | paused | idle | 466 +-------------------+--------------------+ 468 Note: Although there is no mapping for the "gone" chat state, receipt 469 of the "gone" state can be used as a trigger for terminating the 470 formal chat session within MSRP. 472 6. Delivery Reports 474 Both XMPP and MSRP enable a user agent to receive notifications when 475 a message has been received by the intended recipient. 477 For XMPP, the Message Receipts specification [XEP-0184] defines a 478 method and XML namespace for requesting and returning indications 479 that a message has been received by a client controlled by the 480 intended recipient. 482 For MSRP, a native reporting feature is included, in the form of 483 report chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 485 Examples follow. 487 First, the XMPP user sends a message containing a request for 488 delivery notification. 490 Example: Juliet sends a message with a receipt request 492 | 496 | 711609sa 497 | What man art thou ...? 498 | 499 | 501 Example: Gateway transforms XMPP message to MSRP 503 | MSRP a786hjs2 SEND 504 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 505 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 506 | Message-ID: 87652491 507 | Byte-Range: 1-25/25 508 | Success-Report: yes 509 | Failure-Report: no 510 | Content-Type: text/plain 511 | 512 | What man art thou ...? 513 | -------a786hjs2$ 515 Next, the recipient returns a report. 517 Example: Recipient returns receipt 519 | MSRP hx74g336 REPORT 520 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 521 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 522 | Message-ID: 87652491 523 | Byte-Range: 1-106/106 524 | Status: 000 200 OK 525 | -------hx74g336$ 527 Example: Transformed message receipt 529 | 532 | 533 | 535 7. IANA Considerations 537 This document requests no actions of IANA. 539 8. Security Considerations 541 Detailed security considerations for instant messaging protocols are 542 given in [RFC2779], for SIP-based instant messaging in [RFC3428] (see 543 also [RFC3261]), and for XMPP-based instant messaging in [RFC6121] 544 (see also [RFC6120]). 546 This document specifies methods for exchanging instant messages 547 through a gateway that translates between SIP and XMPP. Such a 548 gateway MUST be compliant with the minimum security requirements of 549 the instant messaging protocols for which it translates (i.e., SIP 550 and XMPP). The addition of gateways to the security model of instant 551 messaging specified in [RFC2779] introduces some new risks. In 552 particular, end-to-end security properties (especially 553 confidentiality and integrity) between instant messaging user agents 554 that interface through a SIMPLE-XMPP gateway can be provided only if 555 common formats are supported. Specification of those common formats 556 is out of scope for this document, although it is recommended to use 557 [RFC3862] for instant messages. 559 9. References 560 9.1. Normative References 562 [I-D.ietf-stox-core] 563 Saint-Andre, P., Houri, A., and J. Hildebrand, 564 "Interworking between the Session Initiation Protocol 565 (SIP) and the Extensible Messaging and Presence Protocol 566 (XMPP): Core", draft-ietf-stox-core-04 (work in progress), 567 July 2013. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 573 A., Peterson, J., Sparks, R., Handley, M., and E. 574 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 575 June 2002. 577 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 578 Messaging (CPIM): Message Format", RFC 3862, August 2004. 580 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 581 Instant Messaging", RFC 3994, January 2005. 583 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 584 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 586 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 587 Protocol (XMPP): Core", RFC 6120, March 2011. 589 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 590 Protocol (XMPP): Instant Messaging and Presence", 591 RFC 6121, March 2011. 593 [XEP-0085] 594 Saint-Andre, P. and D. Smith, "Chat State Notifications", 595 XSF XEP 0085, September 2009. 597 [XEP-0184] 598 Saint-Andre, P. and J. Hildebrand, "Message Delivery 599 Receipts", XSF XEP 0184, March 2011. 601 9.2. Informative References 603 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 604 / Presence Protocol Requirements", RFC 2779, 605 February 2000. 607 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 608 and D. Gurle, "Session Initiation Protocol (SIP) Extension 609 for Instant Messaging", RFC 3428, December 2002. 611 Appendix A. Acknowledgements 613 Some text in this document was borrowed from [I-D.ietf-stox-core]. 615 Thanks to Adrian Georgescu, Saul Ibarra, and Tory Patnoe for their 616 feedback. 618 Authors' Addresses 620 Peter Saint-Andre 621 Cisco Systems, Inc. 622 1899 Wynkoop Street, Suite 600 623 Denver, CO 80202 624 USA 626 Phone: +1-303-308-3282 627 Email: psaintan@cisco.com 629 Salvatore Loreto 630 Ericsson 631 Hirsalantie 11 632 Jorvas 02420 633 Finland 635 Email: Salvatore.Loreto@ericsson.com 637 Eddy Gavita 638 Ericsson 639 Decarie Boulevard 640 Town of Mount Royal, Quebec 641 Canada 643 Email: eddy.gavita@ericsson.com 644 Nazin Hossain 645 Ericsson 646 Decarie Boulevard 647 Town of Mount Royal, Quebec 648 Canada 650 Email: Nazin.Hossain@ericsson.com