idnits 2.17.1 draft-ietf-stox-chat-09.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 (February 2, 2015) is 3371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0085' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0184' == Outdated reference: A later version (-13) exists of draft-ietf-stox-im-10 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 &yet 4 Intended status: Standards Track S. Loreto 5 Expires: August 6, 2015 Ericsson 6 February 2, 2015 8 Interworking between the Session Initiation Protocol (SIP) and the 9 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat 10 Sessions 11 draft-ietf-stox-chat-09 13 Abstract 15 This document defines a bidirectional protocol mapping for the 16 exchange of instant messages in the context of a one-to-one chat 17 session between a user of the Session Initiation Protocol (SIP) and a 18 user of the Extensible Messaging and Presence Protocol (XMPP). 19 Specifically for SIP text chat, this document specifies a mapping to 20 the Message Session Relay Protocol (MSRP). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 6, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Composing Events . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . 15 63 8. Internationalization Considerations . . . . . . . . . . . . . 16 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 70 1. Introduction 72 Both the Session Initiation Protocol (SIP) [RFC3261] and the 73 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 74 used for the purpose of one-to-one text chat over the Internet. To 75 ensure interworking between these technologies, it is important to 76 define bidirectional protocol mappings. 78 The architectural assumptions underlying such protocol mappings are 79 provided in [RFC7247], including mapping of addresses and error 80 conditions. This document specifies mappings for one-to-one text 81 chat sessions (sometimes called "session-mode" messaging); in 82 particular, this document specifies mappings between XMPP messages of 83 type "chat" and the Message Session Relay Protocol (MSRP) [RFC4975], 84 which is commonly used in SIP-based systems for chat functionality 85 (although note that MSRP is not conjoined to SIP, and can be used by 86 non-SIP technologies). Mappings for single instant messages and 87 groupchat are provided in separate documents. 89 The approach taken here is to directly map syntax and semantics from 90 one protocol to another. The mapping described herein depends on the 91 protocols defined in the following specifications: 93 o XMPP chat sessions using message stanzas of type "chat" are 94 specified in [RFC6121]. 96 o MSRP chat sessions using the SIP INVITE and SEND request types are 97 specified in [RFC4975]. 99 In SIP-based systems that use MSRP, a chat session is formally 100 negotiated just as any other session type is using SIP. By contrast, 101 a one-to-one chat "session" in XMPP is an informal construct and is 102 not formally negotiated: a user simply sends a message of type "chat" 103 to a contact, the contact then replies to the message, and the sum 104 total of such messages exchanged during a defined period of time is 105 considered to be a chat session (ideally tied together using an XMPP 106 element as described in Section 5.1 of [RFC6121]). To 107 overcome the disparity between these approaches, a gateway that 108 wishes to map between SIP/MSRP and XMPP for one-to-one chat sessions 109 needs to maintain some additional state, as described below. 111 2. Intended Audience 113 The documents in this series are intended for use by software 114 developers who have an existing system based on one of these 115 technologies (e.g., SIP), and would like to enable communication from 116 that existing system to systems based on the other technology (e.g., 117 XMPP). We assume that readers are familiar with the core 118 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the 119 base document for this series [RFC7247], and with the following chat- 120 related specifications: 122 o The Message Session Relay Protocol (MSRP) [RFC4975] 124 o Extensible Messaging and Presence Protocol: Instant Messaging and 125 Presence [RFC6121] 127 o Indication of Message Composition for Instant Messaging [RFC3994] 129 o Chat State Notifications [XEP-0085] 131 Note well that not all protocol-compliant messages are shown (such as 132 SIP 100 TRYING messages), in order to focus the reader on the 133 essential aspects of the protocol flows. 135 3. Terminology 137 A number of terms used here are explained in [RFC3261], [RFC4975], 138 [RFC6120], and [RFC6121]. 140 In flow diagrams, SIP/MSRP traffic is shown using arrows such as 141 "***>" whereas XMPP traffic is shown using arrows such as "...>". 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119]. 148 4. XMPP to MSRP 150 In XMPP, the "informal session" approach is to simply send someone a 151 of type "chat" without starting any session negotiation 152 ahead of time (as described in [RFC6121]). The XMPP "informal 153 session" approach maps very well into a SIP MESSAGE request, as 154 described in [RFC7247]. However, the XMPP informal session approach 155 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains 156 additional state. The order of events is as follows. 158 XMPP XMPP XMPP-to-MSRP SIP SIP 159 User Server Gateway Server User 160 | | | | | 161 | (F1) XMPP | | | | 162 | message | | | | 163 |..............>| | | | 164 | | (F2) XMPP | | | 165 | | message | | | 166 | |..............>| | | 167 | | | (F3) SIP | | 168 | | | INVITE | | 169 | | |**************>| | 170 | | | | (F4) SIP | 171 | | | | INVITE | 172 | | | |**************>| 173 | | | | (F5) SIP | 174 | | | | 200 OK | 175 | | | |<**************| 176 | | | (F6) SIP | | 177 | | | 200 OK | | 178 | | |<**************| | 179 | | | (F7) SIP ACK | | 180 | | |**************>| | 181 | | | | (F8) SIP ACK | 182 | | | |**************>| 183 | | | (F9) MSRP SEND | 184 | | |******************************>| 185 . . . . . 186 . . . . . 187 | | | (F10) MSRP SEND | 188 | | |<******************************| 189 | | (F11) XMPP | | | 190 | | message | | | 191 | |<..............| | | 192 | (F12) XMPP | | | | 193 | message | | | | 194 |<..............| | | | 195 . . . . . 196 . . . . . 197 | | | | (F13) SIP BYE | 198 | | | |<**************| 199 | | | (F14) SIP BYE | | 200 | | |<**************| | 201 | | | (F15) SIP | | 202 | | | 200 OK | | 203 | | |**************>| | 204 | | | | (F16) SIP | 205 | | | | 200 OK | 206 | | | |**************>| 208 Figure 1: XMPP to MSRP Order of Events 210 The mapping of XMPP syntax to SIP syntax MUST be as shown in the 211 following table. (Mappings for several aspects not mentioned here 212 are specified in [I-D.ietf-stox-im].) 214 Table 1: Message syntax mapping from XMPP to SIP 216 +-----------------------------+--------------------------+ 217 | XMPP Element or Attribute | SIP Header or Contents | 218 +-----------------------------+--------------------------+ 219 | | Call-ID | 220 | id | transaction identifier | 221 +-----------------------------+--------------------------+ 223 First the XMPP user would generate an XMPP chat message. 225 Example 1: Juliet sends XMPP message (F1) 227 | 231 | 29377446-0CBB-4296-8958-590D79094C50 232 | Art thou not Romeo, and a Montague? 233 | 235 Upon receiving such a message stanza, the XMPP server needs to 236 determine the identity of the domainpart in the 'to' address, which 237 it does by following the procedures explained in Section 5 of 238 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand 239 off the message stanza to an XMPP-to-SIP gateway or connection 240 manager that natively communicates with MSRP-aware SIP servers. 242 The XMPP-to-SIP gateway at the XMPP server would then initiate an 243 MSRP session with Romeo on Juliet's behalf (since there is no 244 reliable way for the gateway to determine whether Romeo's client 245 supports MSRP, if that is not the case then MSRP session initiation 246 might result in an error). 248 Example 2: Gateway starts SIP session on behalf of Juliet (F3) 250 | INVITE sip:romeo@example.net SIP/2.0 251 | To: 252 | From: 253 | Contact: ;gr=yn0cl4bnw0yr3vym 254 | Subject: Open chat with Juliet? 255 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 256 | Content-Type: application/sdp 257 | 258 | c=IN IP4 x2s.example.com 259 | m=message 7654 TCP/MSRP * 260 | a=accept-types:text/plain 261 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 263 Here we assume that Romeo's client supports MSRP and that Romeo 264 accepts the MSRP session request. 266 Example 3: Romeo accepts session request (F5) 268 | SIP/2.0 200 OK 269 | To: 270 | From: 271 | Contact: ;gr=dr4hcr0st3lup4c 272 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 273 | Content-Type: application/sdp 274 | 275 | c=IN IP4 s2x.example.net 276 | m=message 12763 TCP/MSRP * 277 | a=accept-types:text/plain 278 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 280 The XMPP-to-SIP gateway then acknowledges the session acceptance on 281 behalf of Juliet. 283 Example 4: Gateway sends ACK to Romeo (F7) 285 | ACK sip:juliet@example.com SIP/2.0 286 | To: ;gr=dr4hcr0st3lup4c 287 | From: 288 | Contact: ;gr=yn0cl4bnw0yr3vym 289 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 291 The XMPP-to-SIP gateway then transforms the original XMPP chat 292 message into MSRP. 294 Example 5: Gateway maps XMPP message to MSRP (F9) 296 | MSRP a786hjs2 SEND 297 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 298 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 299 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A 300 | Byte-Range: 1-25/25 301 | Content-Type: text/plain 302 | 303 | Art thou not Romeo, and a Montague? 304 | -------a786hjs2$ 306 Romeo can then send a reply using his MSRP client. 308 Example 6: Romeo sends reply (F10) 310 | MSRP di2fs53v SEND 311 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 312 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 313 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA 314 | Byte-Range: 1-25/25 315 | Failure-Report: no 316 | Content-Type: text/plain 317 | 318 | Neither, fair saint, if either thee dislike. 319 | -------di2fs53v$ 321 The SIP-to-XMPP gateway would then transform that message into 322 appropriate XMPP syntax for routing to the intended recipient. 324 Example 7: Gateway maps MSRP message to XMPP (F11) 326 | 330 | 29377446-0CBB-4296-8958-590D79094C50 331 | Neither, fair saint, if either thee dislike. 332 | 334 When the MSRP user wishes to end the chat session, the user's MSRP 335 client sends a SIP BYE. 337 Example 8: Romeo terminates chat session (F13) 339 | BYE juliet@example.com sip: SIP/2.0 340 | From: ;tag=087js 341 | To: ;tag=786 342 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 343 | Cseq: 1 BYE 344 | Content-Length: 0 346 The BYE is then acknowledged by the XMPP-to-SIP gateway. 348 Example 9: Gateway acknowledges termination (F15) 350 | SIP/2.0 200 OK 351 | From: ;tag=786 352 | To: ;tag=087js 353 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 354 | CSeq: 1 BYE 355 | Content-Length: 0 357 Because there is no formal session on the XMPP side, there is no 358 corresponding communication from the gateway to the XMPP user. 359 However, it is reasonable for the gateway to send a "gone" chat state 360 notification [XEP-0085], as described under Section 6.1. 362 5. MSRP to XMPP 364 When an MSRP client sends messages through a gateway to an XMPP 365 client, the order of events is as follows. 367 SIP SIP MSRP-to-XMPP XMPP XMPP 368 User Server Gateway Server User 369 | | | | | 370 | (F17) SIP | | | | 371 | INVITE | | | | 372 |**************>| | | | 373 | | (F18) SIP | | | 374 | | INVITE | | | 375 | |**************>| | | 376 | | (F19) SIP | | | 377 | | 200 OK | | | 378 | |<**************| | | 379 | (F20) SIP | | | | 380 | 200 OK | | | | 381 |<**************| | | | 382 | (F21) SIP ACK | | | | 383 |**************>| | | | 384 | | (F22) SIP ACK | | | 385 | |**************>| | | 386 | (F23) MSRP SEND | | | 387 |******************************>| | | 388 | | | (F24) XMPP | | 389 | | | message | | 390 | | |..............>| | 391 | | | | (F25) XMPP | 392 | | | | message | 393 | | | |..............>| 394 . . . . . 395 . . . . . 396 | | | | (F26) XMPP | 397 | | | | message | 398 | | | |<..............| 399 | | | (F27) XMPP | | 400 | | | message | | 401 | | |<..............| | 402 | (F28) MSRP SEND | | | 403 |<******************************| | | 404 . . . . . 405 . . . . . 406 | | | | | 407 | | | | | 408 | (F29) SIP BYE | | | | 409 |**************>| | | | 410 | | (F30) SIP BYE | | | 411 | |**************>| | | 412 | | (F31) SIP | | | 413 | | 200 OK | | | 414 | |<**************| | | 415 | (F32) SIP | | | | 416 | 200 OK | | | | 417 |<**************| | | | 419 Figure 2: MSRP to XMPP Order of Events 421 The mapping of SIP syntax to XMPP syntax MUST be as shown in the 422 following table. (Mappings for several aspects not mentioned here 423 are specified in [I-D.ietf-stox-im].) 425 Table 2: Message syntax mapping from SIP to XMPP 427 +--------------------------+-----------------------------+ 428 | SIP Header or Contents | XMPP Element or Attribute | 429 +--------------------------+-----------------------------+ 430 | Call-ID | | 431 | transaction identifier | id | 432 +--------------------------+-----------------------------+ 434 The protocol flow begins when Romeo starts a chat session with 435 Juliet. 437 Example 10: Romeo starts chat session (F17) 439 | INVITE sip:juliet@example.com SIP/2.0 440 | To: 441 | From: 442 | Contact: ;gr=dr4hcr0st3lup4c 443 | Subject: Open chat with Romeo? 444 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 445 | Content-Type: application/sdp 446 | 447 | c=IN IP4 s2x.example.net 448 | m=message 7313 TCP/MSRP * 449 | a=accept-types:text/plain 450 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 452 Upon receiving the INVITE, the SIP (MSRP) server needs to determine 453 the identity of the domain portion of the Request-URI or To header, 454 which it does by following the procedures explained in Section 5 of 455 [RFC7247]. If the domain is an XMPP domain, the SIP server will hand 456 off the INVITE to an associated MSRP-to-XMPP gateway or connection 457 manager that natively communicates with XMPP servers. 459 Example 11: Gateway accepts session on Juliet's behalf (F19) 461 | SIP/2.0 200 OK 462 | To: ;gr=dr4hcr0st3lup4c 463 | From: 464 | Contact: ;gr=yn0cl4bnw0yr3vym 465 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 466 | Content-Type: application/sdp 467 | 468 | c=IN IP4 x2s.example.com 469 | m=message 8763 TCP/MSRP * 470 | a=accept-types:text/plain 471 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 473 Example 12: Romeo sends ACK (F21) 475 | ACK sip:juliet@example.com SIP/2.0 476 | To: ;gr=yn0cl4bnw0yr3vym 477 | From: 478 | Contact: ;gr=dr4hcr0st3lup4c 479 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 481 Example 13: Romeo sends message (F23) 483 | MSRP ad49kswow SEND 484 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 485 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 486 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 487 | Byte-Range: 1-32/32 488 | Failure-Report: no 489 | Content-Type: text/plain 490 | 491 | I take thee at thy word ... 492 | -------ad49kswow$ 494 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24) 496 | 500 | F6989A8C-DE8A-4E21-8E07-F0898304796F 501 | I take thee at thy word ... 502 | 503 Example 15: Juliet sends reply (F26) 505 | 509 | 29377446-0CBB-4296-8958-590D79094C50 510 | What man art thou ...? 511 | 513 Example 16: Gateway maps XMPP message to MSRP (F28) 515 | MSRP ms53b7z9 SEND 516 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 517 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 518 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 519 | Byte-Range: 1-25/25 520 | Failure-Report: no 521 | Content-Type: text/plain 522 | 523 | What man art thou ...? 524 | -------ms53b7z9$ 526 Example 17: Romeo terminates chat session (F29) 528 | BYE juliet@example.com sip: SIP/2.0 529 | To: ;gr=yn0cl4bnw0yr3vym 530 | From: 531 | Contact: ;gr=dr4hcr0st3lup4c 532 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 533 | Cseq: 1 BYE 534 | Content-Length: 0 536 Example 18: Gateway acknowledges termination of session on behalf of 537 Juliet (F31) 539 | SIP/2.0 200 OK 540 | To: ;gr=yn0cl4bnw0yr3vym 541 | From: 542 | Contact: ;gr=dr4hcr0st3lup4c 543 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 544 | CSeq: 1 BYE 546 6. Composing Events 548 Both XMPP and MSRP enable a client to receive notifications when a 549 person's conversation partner is composing an instant message within 550 the context of a chat session. 552 For XMPP, the Chat State Notifications specification [XEP-0085] 553 defines five states: active, inactive, gone, composing, and paused. 554 Some of these states are related to the act of message composition 555 (composing, paused), whereas others are related to the sender's 556 involvement with the chat session (active, inactive, gone). Note 557 that the "gone" chat state is not to be confused with the 558 stanza error condition defined in [RFC6120]. 560 For MSRP (and SIP/SIMPLE in general), the Indication of Message 561 Composition for Instant Messaging specification [RFC3994] defines two 562 states: idle and active. Here the idle state indicates that the 563 sender is not actively composing a message, and the active state 564 indicates that the sender is indeed actively composing a message (the 565 sending client simply toggles between the two states, changing to 566 active if the user is actively composing a message and changing to 567 idle if the user is no longer actively composing a message). 569 Because the XEP-0085 states can represent information that is not 570 captured in RFC 3994, gateways can either (a) map only the composing- 571 related states or (b) map all the XEP-0085 states. 573 The following mappings are suggested. 575 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states 577 +-------------------+--------------------+ 578 | isComposing Event | Chat State | 579 +-------------------+--------------------+ 580 | active | composing | 581 | idle | active | 582 +-------------------+--------------------+ 584 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events 586 +-------------------+--------------------+ 587 | Chat State | isComposing Event | 588 +-------------------+--------------------+ 589 | active | idle | 590 | inactive | idle | 591 | gone | [none, see note] | 592 | composing | active | 593 | paused | idle | 594 +-------------------+--------------------+ 596 6.1. Use of the Gone Chat State 598 Although there is no direct mapping for the "gone" chat state to an 599 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP 600 gateway can serve as a trigger for terminating the formal chat 601 session within MSRP, i.e., for sending a SIP BYE for the session from 602 the XMPP-to-MSRP gateway to the SIP user. The following examples 603 illustrate this indirect mapping (which would occur after step F14 in 604 Figure 1). 606 Example 19: Juliet sends gone chat state 608 | 612 | 29377446-0CBB-4296-8958-590D79094C50 613 | 614 | 616 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE 618 | BYE romeo@example.net sip: SIP/2.0 619 | From: ;tag=786 620 | To: ;tag=087js 621 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 622 | Cseq: 1 BYE 623 | Content-Length: 0 625 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway 626 can serve as a trigger for sending a "gone" chat state notification 627 to the XMPP user. The following examples illustrate this indirect 628 mapping (which would occur after step F30 in Figure 2). 630 Example 21: Romeo terminates chat session 632 | BYE juliet@example.com sip: SIP/2.0 633 | To: ;gr=yn0cl4bnw0yr3vym 634 | From: 635 | Contact: ;gr=dr4hcr0st3lup4c 636 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 637 | Cseq: 1 BYE 638 | Content-Length: 0 639 Example 22: MSRP-to-XMPP gateway generates gone chat state 641 | 645 | F6989A8C-DE8A-4E21-8E07-F0898304796F 646 | 647 | 649 To enable these uses, gateways that support chat state notifications 650 MUST support the "gone" state (which is merely recommended, not 651 required, by [XEP-0085]). 653 It is also reasonable for gateways to implement timers that 654 automatically trigger a "gone" chat state if the XMPP user has not 655 sent a message within the "session" for a given amount of time. 657 7. Delivery Reports 659 Both XMPP and MSRP enable a client to receive notifications when a 660 message has been received by the intended recipient. 662 For XMPP, the Message Receipts specification [XEP-0184] defines a 663 method and XML namespace for requesting and returning indications 664 that a message has been received by a client controlled by the 665 intended recipient. 667 For MSRP, a native reporting feature is included, in the form of 668 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 670 Examples follow. 672 First, the XMPP user sends a message containing a request for 673 delivery notification. 675 Example 23: Juliet sends XMPP message with receipt request 677 | 681 | 29377446-0CBB-4296-8958-590D79094C50 682 | What man art thou ...? 683 | 684 | 685 Example 24: Gateway maps XMPP message to MSRP 687 | MSRP bf9m36d5 SEND 688 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 689 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 690 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 691 | Byte-Range: 1-25/25 692 | Success-Report: yes 693 | Failure-Report: no 694 | Content-Type: text/plain 695 | 696 | What man art thou ...? 697 | -------bf9m36d5$ 699 Next, the recipient returns a report. 701 Example 25: Romeo returns MSRP receipt 703 | MSRP hx74g336 REPORT 704 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 705 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 706 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 707 | Byte-Range: 1-106/106 708 | Status: 000 200 OK 709 | -------hx74g336$ 711 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP 713 | 716 | 717 | 719 8. Internationalization Considerations 721 Relevant discussion of internationalized text in messages can be 722 found in [I-D.ietf-stox-im]. 724 9. IANA Considerations 726 This document requests no actions of IANA. 728 10. Security Considerations 730 Detailed security considerations for instant messaging protocols are 731 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 732 when SIP is used to negotiate MSRP sessions), and for XMPP-based 733 instant messaging in [RFC6121] (see also [RFC6120]). The security 734 considerations provided in [RFC7247] also apply. 736 This document specifies methods for exchanging instant messages 737 through a gateway that translates between SIP/MSRP and XMPP. Such a 738 gateway MUST be compliant with the minimum security requirements of 739 the textual chat protocols for which it translates (i.e., MSRP and 740 XMPP). The addition of gateways to the security model of instant 741 messaging specified in [RFC2779] introduces some new risks. In 742 particular, end-to-end security properties (especially 743 confidentiality and integrity) between instant messaging clients that 744 interface through an MSRP-XMPP gateway can be provided only if common 745 formats are supported. Specification of those common formats is out 746 of scope for this document, although it is suggested to use [RFC3862] 747 for instant messages. 749 11. References 751 11.1. Normative References 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 757 A., Peterson, J., Sparks, R., Handley, M., and E. 758 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 759 June 2002. 761 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 762 Messaging (CPIM): Message Format", RFC 3862, August 2004. 764 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 765 Instant Messaging", RFC 3994, January 2005. 767 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 768 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 770 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 771 Protocol (XMPP): Core", RFC 6120, March 2011. 773 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 774 Protocol (XMPP): Instant Messaging and Presence", RFC 775 6121, March 2011. 777 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, 778 "Interworking between the Session Initiation Protocol 779 (SIP) and the Extensible Messaging and Presence Protocol 780 (XMPP): Architecture, Addresses, and Error Handling", RFC 781 7247, May 2014. 783 [XEP-0085] 784 Saint-Andre, P. and D. Smith, "Chat State Notifications", 785 XSF XEP 0085, September 2009. 787 [XEP-0184] 788 Saint-Andre, P. and J. Hildebrand, "Message Delivery 789 Receipts", XSF XEP 0184, March 2011. 791 11.2. Informative References 793 [I-D.ietf-stox-im] 794 Saint-Andre, P., Houri, A., and J. Hildebrand, 795 "Interworking between the Session Initiation Protocol 796 (SIP) and the Extensible Messaging and Presence Protocol 797 (XMPP): Instant Messaging", draft-ietf-stox-im-10 (work in 798 progress), August 2014. 800 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 801 / Presence Protocol Requirements", RFC 2779, February 802 2000. 804 Appendix A. Acknowledgements 806 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an 807 early version of this document. 809 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, 810 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for 811 their feedback. 813 The authors gratefully acknowledge the assistance of Markus Isomaki 814 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 815 and Alissa Cooper as the sponsoring Area Directors. 817 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 818 employing him during his work on earlier versions of this document. 820 Authors' Addresses 821 Peter Saint-Andre 822 &yet 824 Email: peter@andyet.com 825 URI: https://andyet.com/ 827 Salvatore Loreto 828 Ericsson 829 Hirsalantie 11 830 Jorvas 02420 831 Finland 833 Email: Salvatore.Loreto@ericsson.com