idnits 2.17.1 draft-ietf-stox-chat-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 (June 9, 2014) is 3608 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-08 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: December 11, 2014 Ericsson 6 June 9, 2014 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-07 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 December 11, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 14 63 8. Internationalization Considerations . . . . . . . . . . . . . 16 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 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 3. Terminology 133 A number of terms used here are explained in [RFC3261], [RFC4975], 134 [RFC6120], and [RFC6121]. 136 In flow diagrams, SIP/MSRP traffic is shown using arrows such as 137 "***>" whereas XMPP traffic is shown using arrows such as "...>". 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 [RFC2119]. 144 4. XMPP to MSRP 146 In XMPP, the "informal session" approach is to simply send someone a 147 of type "chat" without starting any session negotiation 148 ahead of time (as described in [RFC6121]). The XMPP "informal 149 session" approach maps very well into a SIP MESSAGE request, as 150 described in [RFC7247]. However, the XMPP informal session approach 151 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains 152 additional state. The order of events is as follows. 154 XMPP XMPP XMPP-to-MSRP SIP SIP 155 User Server Gateway Server User 156 | | | | | 157 | (F1) XMPP | | | | 158 | message | | | | 159 |..............>| | | | 160 | | (F2) XMPP | | | 161 | | message | | | 162 | |..............>| | | 163 | | | (F3) SIP | | 164 | | | INVITE | | 165 | | |**************>| | 166 | | | | (F4) SIP | 167 | | | | INVITE | 168 | | | |**************>| 169 | | | | (F5) SIP | 170 | | | | 200 OK | 171 | | | |<**************| 172 | | | (F6) SIP | | 173 | | | 200 OK | | 174 | | |<**************| | 175 | | | (F7) SIP ACK | | 176 | | |**************>| | 177 | | | | (F8) SIP ACK | 178 | | | |**************>| 179 | | | (F9) MSRP SEND | 180 | | |******************************>| 181 . . . . . 182 . . . . . 183 | | | (F10) MSRP SEND | 184 | | |<******************************| 185 | | (F11) XMPP | | | 186 | | message | | | 187 | |<..............| | | 188 | (F12) XMPP | | | | 189 | message | | | | 190 |<..............| | | | 191 . . . . . 193 . . . . . 194 | | | | (F13) SIP BYE | 195 | | | |<**************| 196 | | | (F14) SIP BYE | | 197 | | |<**************| | 198 | | | (F15) SIP | | 199 | | | 200 OK | | 200 | | |**************>| | 201 | | | | (F16) SIP | 202 | | | | 200 OK | 203 | | | |**************>| 205 Figure 1: XMPP to MSRP Order of Events 207 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the 208 following table. (Mappings for several aspects not mentioned here 209 are specified in [I-D.ietf-stox-im].) 211 Table 1: Message syntax mapping from XMPP to SIP 213 +-----------------------------+--------------------------+ 214 | XMPP Element or Attribute | SIP Header or Contents | 215 +-----------------------------+--------------------------+ 216 | | Call-ID | 217 | id | transaction identifier | 218 +-----------------------------+--------------------------+ 220 First the XMPP user would generate an XMPP chat message. 222 Example 1: Juliet sends XMPP message (F1) 224 | 228 | 29377446-0CBB-4296-8958-590D79094C50 229 | Art thou not Romeo, and a Montague? 230 | 232 Upon receiving such a message stanza, the XMPP server needs to 233 determine the identity of the domainpart in the 'to' address, which 234 it does by following the procedures explained in Section 5 of 235 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand 236 off the message stanza to an XMPP-to-SIP gateway or connection 237 manager that natively communicates with MSRP-aware SIP servers. 239 The XMPP-to-SIP gateway at the XMPP server would then initiate an 240 MSRP session with Romeo on Juliet's behalf (since there is no 241 reliable way for the gateway to determine if Romeo's client supports 242 MSRP, it simply needs to guess). 244 Example 2: Gateway starts SIP session on behalf of Juliet (F3) 246 | INVITE sip:romeo@example.net SIP/2.0 247 | To: 248 | From: 249 | Contact: ;gr=balcony 250 | Subject: Open chat with Juliet? 251 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 252 | Content-Type: application/sdp 253 | 254 | c=IN IP4 x2s.example.com 255 | m=message 7654 TCP/MSRP * 256 | a=accept-types:text/plain 257 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 259 Here we assume that Romeo accepts the MSRP session request. 261 Example 3: Romeo accepts session request (F5) 263 | SIP/2.0 200 OK 264 | To: 265 | From: 266 | Contact: ;gr=orchard 267 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 268 | Content-Type: application/sdp 269 | 270 | c=IN IP4 s2x.example.net 271 | m=message 12763 TCP/MSRP * 272 | a=accept-types:text/plain 273 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 275 The XMPP-to-SIP gateway then acknowledges the session acceptance on 276 behalf of Juliet. 278 Example 4: Gateway sends ACK to Romeo (F7) 280 | ACK sip:juliet@example.com SIP/2.0 281 | To: ;gr=orchard 282 | From: 283 | Contact: ;gr=balcony 284 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 286 The XMPP-to-SIP gateway then transforms the original XMPP chat 287 message into MSRP. 289 Example 5: Gateway maps XMPP message to MSRP (F9) 291 | MSRP a786hjs2 SEND 292 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 293 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 294 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A 295 | Byte-Range: 1-25/25 296 | Content-Type: text/plain 297 | 298 | Art thou not Romeo, and a Montague? 299 | -------a786hjs2$ 301 Romeo can then send a reply using his MSRP client. 303 Example 6: Romeo sends reply (F10) 305 | MSRP di2fs53v SEND 306 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 307 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 308 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA 309 | Byte-Range: 1-25/25 310 | Failure-Report: no 311 | Content-Type: text/plain 312 | 313 | Neither, fair saint, if either thee dislike. 314 | -------di2fs53v$ 316 The SIP-to-XMPP gateway would then transform that message into 317 appropriate XMPP syntax for routing to the intended recipient. 319 Example 7: Gateway maps MSRP message to XMPP (F11) 321 | 325 | 29377446-0CBB-4296-8958-590D79094C50 326 | Neither, fair saint, if either thee dislike. 327 | 329 When the MSRP user wishes to end the chat session, the user's MSRP 330 client sends a SIP BYE. 332 Example 8: Romeo terminates chat session (F13) 334 | BYE juliet@example.com sip: SIP/2.0 335 | From: ;tag=087js 336 | To: ;tag=786 337 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 338 | Cseq: 1 BYE 339 | Content-Length: 0 341 The BYE is then acknowledged by the XMPP-to-SIP gateway. 343 Example 9: Gateway acknowledges termination (F15) 345 | SIP/2.0 200 OK 346 | From: ;tag=786 347 | To: ;tag=087js 348 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 349 | CSeq: 1 BYE 350 | Content-Length: 0 352 Because there is no formal session on the XMPP side, there is no 353 corresponding communication from the gateway to the XMPP user. 354 However, it is reasonable for the gateway to send a "gone" chat state 355 notification [XEP-0085], as described under Section 6.1. 357 5. MSRP to XMPP 359 When an MSRP client sends messages through a gateway to an XMPP 360 client, the order of events is as follows. 362 SIP SIP MSRP-to-XMPP XMPP XMPP 363 User Server Gateway Server User 364 | | | | | 365 | (F17) SIP | | | | 366 | INVITE | | | | 367 |**************>| | | | 368 | | (F18) SIP | | | 369 | | INVITE | | | 370 | |**************>| | | 371 | | (F19) SIP | | | 372 | | 200 OK | | | 373 | |<**************| | | 374 | (F20) SIP | | | | 375 | 200 OK | | | | 376 |<**************| | | | 377 | (F21) SIP ACK | | | | 378 |**************>| | | | 379 | | (F22) SIP ACK | | | 380 | |**************>| | | 381 | (F23) MSRP SEND | | | 382 |******************************>| | | 383 | | | (F24) XMPP | | 384 | | | message | | 385 | | |..............>| | 386 | | | | (F25) XMPP | 387 | | | | message | 388 | | | |..............>| 389 . . . . . 390 . . . . . 391 | | | | (F26) XMPP | 392 | | | | message | 393 | | | |<..............| 394 | | | (F27) XMPP | | 395 | | | message | | 396 | | |<..............| | 397 | (F28) MSRP SEND | | | 398 |<******************************| | | 399 . . . . . 400 . . . . . 401 | | | | | 402 | | | | | 403 | (F29) SIP BYE | | | | 404 |**************>| | | | 405 | | (F30) SIP BYE | | | 406 | |**************>| | | 407 | | (F31) SIP | | | 408 | | 200 OK | | | 409 | |<**************| | | 410 | (F36) SIP | | | | 411 | 200 OK | | | | 412 |<**************| | | | 414 Figure 2: MSRP to XMPP Order of Events 416 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the 417 following table. (Mappings for several aspects not mentioned here 418 are specified in [I-D.ietf-stox-im].) 420 Table 2: Message syntax mapping from SIP to XMPP 422 +--------------------------+-----------------------------+ 423 | SIP Header or Contents | XMPP Element or Attribute | 424 +--------------------------+-----------------------------+ 425 | Call-ID | | 426 | transaction identifier | id | 427 +--------------------------+-----------------------------+ 429 The protocol flow begins when Romeo starts a chat session with 430 Juliet. 432 Example 10: Romeo starts chat session (F17) 434 | INVITE sip:juliet@example.com SIP/2.0 435 | To: 436 | From: 437 | Contact: ;gr=orchard 438 | Subject: Open chat with Romeo? 439 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 440 | Content-Type: application/sdp 441 | 442 | c=IN IP4 s2x.example.net 443 | m=message 7313 TCP/MSRP * 444 | a=accept-types:text/plain 445 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 447 Upon receiving the INVITE, the SIP (MSRP) server needs to determine 448 the identity of the domain portion of the Request-URI or To header, 449 which it does by following the procedures explained in Section 5 of 450 [RFC7247]. If the domain is an XMPP domain, the SIP server will hand 451 off the INVITE to an associated MSRP-to-XMPP gateway or connection 452 manager that natively communicates with XMPP servers. 454 Example 11: Gateway accepts session on Juliet's behalf (F19) 456 | SIP/2.0 200 OK 457 | To: ;gr=orchard 458 | From: 459 | Contact: ;gr=balcony 460 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 461 | Content-Type: application/sdp 462 | 463 | c=IN IP4 x2s.example.com 464 | m=message 8763 TCP/MSRP * 465 | a=accept-types:text/plain 466 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 468 Example 12: Romeo sends ACK (F21) 470 | ACK sip:juliet@example.com SIP/2.0 471 | To: ;gr=balcony 472 | From: 473 | Contact: ;gr=orchard 474 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 475 Example 13: Romeo sends message (F23) 477 | MSRP ad49kswow SEND 478 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 479 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 480 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 481 | Byte-Range: 1-32/32 482 | Failure-Report: no 483 | Content-Type: text/plain 484 | 485 | I take thee at thy word ... 486 | -------ad49kswow$ 488 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24) 490 | 494 | F6989A8C-DE8A-4E21-8E07-F0898304796F 495 | I take thee at thy word ... 496 | 498 Example 15: Juliet sends reply (F26) 500 | 504 | 29377446-0CBB-4296-8958-590D79094C50 505 | What man art thou ...? 506 | 508 Example 16: Gateway maps XMPP message to MSRP (F28) 510 | MSRP ms53b7z9 SEND 511 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 512 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 513 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 514 | Byte-Range: 1-25/25 515 | Failure-Report: no 516 | Content-Type: text/plain 517 | 518 | What man art thou ...? 519 | -------ms53b7z9$ 520 Example 17: Romeo terminates chat session (F29) 522 | BYE juliet@example.com sip: SIP/2.0 523 | To: ;gr=balcony 524 | From: 525 | Contact: ;gr=orchard 526 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 527 | Cseq: 1 BYE 528 | Content-Length: 0 530 Example 18: Gateway acknowledges termination of session on behalf of 531 Juliet (F31) 533 | SIP/2.0 200 OK 534 | To: ;gr=balcony 535 | From: 536 | Contact: ;gr=orchard 537 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 538 | CSeq: 1 BYE 540 6. Composing Events 542 Both XMPP and MSRP enable a client to receive notifications when a 543 person's conversation partner is composing an instant message within 544 the context of a chat session. 546 For XMPP, the Chat State Notifications specification [XEP-0085] 547 defines five states: active, inactive, gone, composing, and paused. 548 Some of these states are related to the act of message composition 549 (composing, paused), whereas others are related to the sender's 550 involvement with the chat session (active, inactive, gone). Note 551 that the "gone" chat state is not to be confused with the 552 stanza error condition defined in [RFC6120]. 554 For MSRP (and SIP/SIMPLE in general), the Indication of Message 555 Composition for Instant Messaging specification [RFC3994] defines two 556 states: idle and active. Here the idle state indicates that the 557 sender is not actively composing a message, and the active state 558 indicates that the sender is indeed actively composing a message (the 559 sending client simply toggles between the two states, changing to 560 active if the user is actively composing a message and changing to 561 idle if the user is no longer actively composing a message). 563 Because the XEP-0085 states can represent information that is not 564 captured in RFC 3994, gateways can either (a) map only the composing- 565 related states or (b) map all the XEP-0085 states. 567 The following mappings are suggested. 569 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states 571 +-------------------+--------------------+ 572 | isComposing Event | Chat State | 573 +-------------------+--------------------+ 574 | active | composing | 575 | idle | active | 576 +-------------------+--------------------+ 578 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events 580 +-------------------+--------------------+ 581 | Chat State | isComposing Event | 582 +-------------------+--------------------+ 583 | active | idle | 584 | inactive | idle | 585 | gone | [none, see note] | 586 | composing | active | 587 | paused | idle | 588 +-------------------+--------------------+ 590 6.1. Use of the Gone Chat State 592 Although there is no direct mapping for the "gone" chat state to an 593 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP 594 gateway can serve as a trigger for terminating the formal chat 595 session within MSRP, i.e., for sending a SIP BYE for the session from 596 the XMPP-to-MSRP gateway to the SIP user. The following examples 597 illustrate this indirect mapping (which would occur after step F14 in 598 Figure 1). 600 Example 19: Juliet sends gone chat state 602 | 606 | 29377446-0CBB-4296-8958-590D79094C50 607 | 608 | 609 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE 611 | BYE romeo@example.net sip: SIP/2.0 612 | From: ;tag=786 613 | To: ;tag=087js 614 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 615 | Cseq: 1 BYE 616 | Content-Length: 0 618 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway 619 can server as a trigger for sending a "gone" chat state notification 620 to the XMPP user. The following examples illustrate this indirect 621 mapping (which would occur after step F30 in Figure 2). 623 Example 21: Romeo terminates chat session 625 | BYE juliet@example.com sip: SIP/2.0 626 | To: ;gr=balcony 627 | From: 628 | Contact: ;gr=orchard 629 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 630 | Cseq: 1 BYE 631 | Content-Length: 0 633 Example 22: MSRP-to-XMPP gateway generates gone chat state 635 | 639 | F6989A8C-DE8A-4E21-8E07-F0898304796F 640 | 641 | 643 To enable these uses, gateways that support chat state notifications 644 MUST support the "gone" state (which is merely recommended, not 645 required, by [XEP-0085]). 647 It is also reasonable for gateways to implement timers that 648 automatically trigger a "gone" chat state if the XMPP user has not 649 sent a message within the "session" for a given amount of time. 651 7. Delivery Reports 653 Both XMPP and MSRP enable a client to receive notifications when a 654 message has been received by the intended recipient. 656 For XMPP, the Message Receipts specification [XEP-0184] defines a 657 method and XML namespace for requesting and returning indications 658 that a message has been received by a client controlled by the 659 intended recipient. 661 For MSRP, a native reporting feature is included, in the form of 662 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 664 Examples follow. 666 First, the XMPP user sends a message containing a request for 667 delivery notification. 669 Example 23: Juliet sends XMPP message with receipt request 671 | 675 | 29377446-0CBB-4296-8958-590D79094C50 676 | What man art thou ...? 677 | 678 | 680 Example 24: Gateway maps XMPP message to MSRP 682 | MSRP bf9m36d5 SEND 683 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 684 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 685 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 686 | Byte-Range: 1-25/25 687 | Success-Report: yes 688 | Failure-Report: no 689 | Content-Type: text/plain 690 | 691 | What man art thou ...? 692 | -------bf9m36d5$ 694 Next, the recipient returns a report. 696 Example 25: Romeo returns MSRP receipt 698 | MSRP hx74g336 REPORT 699 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 700 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 701 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 702 | Byte-Range: 1-106/106 703 | Status: 000 200 OK 704 | -------hx74g336$ 706 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP 708 | 711 | 712 | 714 8. Internationalization Considerations 716 Relevant discussion of internationalized text in messages can be 717 found in [I-D.ietf-stox-im]. 719 9. IANA Considerations 721 This document requests no actions of IANA. 723 10. Security Considerations 725 Detailed security considerations for instant messaging protocols are 726 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 727 when SIP is used to negotiate MSRP sessions), and for XMPP-based 728 instant messaging in [RFC6121] (see also [RFC6120]). The security 729 considerations provided in [RFC7247] also apply. 731 This document specifies methods for exchanging instant messages 732 through a gateway that translates between SIP/MSRP and XMPP. Such a 733 gateway MUST be compliant with the minimum security requirements of 734 the textual chat protocols for which it translates (i.e., MSRP and 735 XMPP). The addition of gateways to the security model of instant 736 messaging specified in [RFC2779] introduces some new risks. In 737 particular, end-to-end security properties (especially 738 confidentiality and integrity) between instant messaging clients that 739 interface through an MSRP-XMPP gateway can be provided only if common 740 formats are supported. Specification of those common formats is out 741 of scope for this document, although it is suggested to use [RFC3862] 742 for instant messages. 744 11. References 746 11.1. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, March 1997. 751 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 752 A., Peterson, J., Sparks, R., Handley, M., and E. 753 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 754 June 2002. 756 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 757 Messaging (CPIM): Message Format", RFC 3862, August 2004. 759 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 760 Instant Messaging", RFC 3994, January 2005. 762 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 763 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 765 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 766 Protocol (XMPP): Core", RFC 6120, March 2011. 768 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 769 Protocol (XMPP): Instant Messaging and Presence", RFC 770 6121, March 2011. 772 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, 773 "Interworking between the Session Initiation Protocol 774 (SIP) and the Extensible Messaging and Presence Protocol 775 (XMPP): Architecture, Addresses, and Error Handling", RFC 776 7247, May 2014. 778 [XEP-0085] 779 Saint-Andre, P. and D. Smith, "Chat State Notifications", 780 XSF XEP 0085, September 2009. 782 [XEP-0184] 783 Saint-Andre, P. and J. Hildebrand, "Message Delivery 784 Receipts", XSF XEP 0184, March 2011. 786 11.2. Informative References 788 [I-D.ietf-stox-im] 789 Saint-Andre, P., Houri, A., and J. Hildebrand, 790 "Interworking between the Session Initiation Protocol 791 (SIP) and the Extensible Messaging and Presence Protocol 792 (XMPP): Instant Messaging", draft-ietf-stox-im-08 (work in 793 progress), March 2014. 795 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 796 / Presence Protocol Requirements", RFC 2779, February 797 2000. 799 Appendix A. Acknowledgements 801 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an 802 early version of this document. 804 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, 805 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for 806 their feedback. 808 The authors gratefully acknowledge the assistance of Markus Isomaki 809 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 810 and Alissa Cooper as the sponsoring Area Directors. 812 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 813 employing him during his work on earlier versions of this document. 815 Authors' Addresses 817 Peter Saint-Andre 818 &yet 819 P.O. Box 787 820 Parker, CO 80134 821 USA 823 Email: peter@andyet.com 825 Salvatore Loreto 826 Ericsson 827 Hirsalantie 11 828 Jorvas 02420 829 Finland 831 Email: Salvatore.Loreto@ericsson.com