idnits 2.17.1 draft-ietf-stox-chat-10.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 13, 2015) is 3360 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 (-13) exists of draft-ietf-stox-im-12 -- 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 &yet 4 Intended status: Standards Track S. Loreto 5 Expires: August 17, 2015 Ericsson 6 February 13, 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-10 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . 14 63 8. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 16 64 9. Internationalization Considerations . . . . . . . . . . . . . 17 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 Both the Session Initiation Protocol (SIP) [RFC3261] and the 74 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 75 used for the purpose of one-to-one text chat over the Internet. To 76 ensure interworking between these technologies, it is important to 77 define bidirectional protocol mappings. 79 The architectural assumptions underlying such protocol mappings are 80 provided in [RFC7247], including mapping of addresses and error 81 conditions. This document specifies mappings for one-to-one text 82 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 (MSRP) [RFC4975], 85 which is commonly used in SIP-based systems for chat functionality 86 (although note that MSRP is not conjoined to SIP, and can be used by 87 non-SIP technologies). Mappings for single instant messages and 88 groupchat are provided in separate documents. 90 The approach taken here is to directly map syntax and semantics from 91 one protocol to another. The mapping described herein depends on the 92 protocols defined in the following specifications: 94 o XMPP chat sessions using message stanzas of type "chat" are 95 specified in [RFC6121]. 97 o MSRP chat sessions using the SIP INVITE and SEND request types are 98 specified in [RFC4975]. 100 In SIP-based systems that use MSRP, a chat session is formally 101 negotiated just as any other session type is using SIP. By contrast, 102 a one-to-one chat "session" in XMPP is an informal construct and is 103 not formally negotiated: a user simply sends a message of type "chat" 104 to a contact, the contact then replies to the message, and the sum 105 total of such messages exchanged during a defined period of time is 106 considered to be a chat session (ideally tied together using an XMPP 107 element as described in Section 5.1 of [RFC6121]). To 108 overcome the disparity between these approaches, a gateway that 109 wishes to map between SIP/MSRP and XMPP for one-to-one chat sessions 110 needs to maintain some additional state, as described below. 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 [RFC7247], and with the following chat- 121 related specifications: 123 o The Message Session Relay Protocol (MSRP) [RFC4975] 125 o Extensible Messaging and Presence Protocol: Instant Messaging and 126 Presence [RFC6121] 128 o Indication of Message Composition for Instant Messaging [RFC3994] 130 o Chat State Notifications [XEP-0085] 132 Note well that not all protocol-compliant messages are shown (such as 133 SIP 100 TRYING messages), in order to focus the reader on the 134 essential aspects of the protocol flows. 136 3. Terminology 138 A number of terms used here are explained in [RFC3261], [RFC4975], 139 [RFC6120], and [RFC6121]. 141 In flow diagrams, SIP/MSRP traffic is shown using arrows such as 142 "***>" whereas XMPP traffic is shown using arrows such as "...>". 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119]. 149 4. XMPP to MSRP 151 In XMPP, the "informal session" approach is to simply send someone a 152 of type "chat" without starting any session negotiation 153 ahead of time (as described in [RFC6121]). The XMPP "informal 154 session" approach maps very well into a SIP MESSAGE request, as 155 described in [RFC7247]. However, the XMPP informal session approach 156 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains 157 additional state. The order of events is as follows. 159 XMPP XMPP XMPP-to-MSRP SIP SIP 160 User Server Gateway Server User 161 | | | | | 162 | (F1) XMPP | | | | 163 | message | | | | 164 |..............>| | | | 165 | | (F2) XMPP | | | 166 | | message | | | 167 | |..............>| | | 168 | | | (F3) SIP | | 169 | | | INVITE | | 170 | | |**************>| | 171 | | | | (F4) SIP | 172 | | | | INVITE | 173 | | | |**************>| 174 | | | | (F5) SIP | 175 | | | | 200 OK | 176 | | | |<**************| 177 | | | (F6) SIP | | 178 | | | 200 OK | | 179 | | |<**************| | 180 | | | (F7) SIP ACK | | 181 | | |**************>| | 182 | | | | (F8) SIP ACK | 183 | | | |**************>| 184 | | | (F9) MSRP SEND | 185 | | |******************************>| 186 . . . . . 187 . . . . . 188 | | | (F10) MSRP SEND | 189 | | |<******************************| 190 | | (F11) XMPP | | | 191 | | message | | | 192 | |<..............| | | 193 | (F12) XMPP | | | | 194 | message | | | | 195 |<..............| | | | 196 . . . . . 197 . . . . . 198 | | | | (F13) SIP BYE | 199 | | | |<**************| 200 | | | (F14) SIP BYE | | 201 | | |<**************| | 202 | | | (F15) SIP | | 203 | | | 200 OK | | 204 | | |**************>| | 205 | | | | (F16) SIP | 206 | | | | 200 OK | 207 | | | |**************>| 209 Figure 1: XMPP to MSRP Order of Events 211 The mapping of XMPP syntax to SIP syntax MUST be as specified in 212 [I-D.ietf-stox-im]. 214 First the XMPP user would generate an XMPP chat message. 216 Example 1: Juliet sends XMPP message (F1) 218 | 222 | 29377446-0CBB-4296-8958-590D79094C50 223 | Art thou not Romeo, and a Montague? 224 | 226 Upon receiving such a message stanza, the XMPP server needs to 227 determine the identity of the domainpart in the 'to' address, which 228 it does by following the procedures explained in Section 5 of 229 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand 230 off the message stanza to an XMPP-to-SIP gateway or connection 231 manager that natively communicates with MSRP-aware SIP servers. 233 The XMPP-to-SIP gateway at the XMPP server would then initiate an 234 MSRP session with Romeo on Juliet's behalf (since there is no 235 reliable way for the gateway to determine whether Romeo's client 236 supports MSRP, if that is not the case then MSRP session initiation 237 might result in an error). 239 Example 2: Gateway starts SIP session on behalf of Juliet (F3) 241 | INVITE sip:romeo@example.net SIP/2.0 242 | To: 243 | From: 244 | Contact: ;gr=yn0cl4bnw0yr3vym 245 | Subject: Open chat with Juliet? 246 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 247 | CSeq: 1 INVITE 248 | Content-Type: application/sdp 249 | 250 | c=IN IP4 x2s.example.com 251 | m=message 7654 TCP/MSRP * 252 | a=accept-types:text/plain 253 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 255 Here we assume that Romeo's client supports MSRP and that Romeo 256 accepts the MSRP session request. 258 Example 3: Romeo accepts session request (F5) 260 | SIP/2.0 200 OK 261 | From: 262 | To: 263 | Contact: ;gr=dr4hcr0st3lup4c 264 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 265 | CSeq: 1 INVITE 266 | Content-Type: application/sdp 267 | 268 | c=IN IP4 s2x.example.net 269 | m=message 12763 TCP/MSRP * 270 | a=accept-types:text/plain 271 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 273 The XMPP-to-SIP gateway then acknowledges the session acceptance on 274 behalf of Juliet. 276 Example 4: Gateway sends ACK to Romeo (F7) 278 | ACK sip:juliet@example.com SIP/2.0 279 | To: ;gr=dr4hcr0st3lup4c 280 | From: 281 | Contact: ;gr=yn0cl4bnw0yr3vym 282 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 283 | CSeq: 2 ACK 285 The XMPP-to-SIP gateway then transforms the original XMPP chat 286 message into MSRP. 288 Example 5: Gateway maps XMPP message to MSRP (F9) 290 | MSRP a786hjs2 SEND 291 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 292 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 293 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A 294 | Byte-Range: 1-25/25 295 | Content-Type: text/plain 296 | 297 | Art thou not Romeo, and a Montague? 298 | -------a786hjs2$ 300 Romeo can then send a reply using his MSRP client. 302 Example 6: Romeo sends reply (F10) 304 | MSRP di2fs53v SEND 305 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 306 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 307 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA 308 | Byte-Range: 1-25/25 309 | Failure-Report: no 310 | Content-Type: text/plain 311 | 312 | Neither, fair saint, if either thee dislike. 313 | -------di2fs53v$ 315 The SIP-to-XMPP gateway would then transform that message into 316 appropriate XMPP syntax for routing to the intended recipient. 318 Example 7: Gateway maps MSRP message to XMPP (F11) 320 | 324 | 29377446-0CBB-4296-8958-590D79094C50 325 | Neither, fair saint, if either thee dislike. 326 | 328 When the MSRP user wishes to end the chat session, the user's MSRP 329 client sends a SIP BYE. 331 Example 8: Romeo terminates chat session (F13) 333 | BYE juliet@example.com sip: SIP/2.0 334 | From: ;tag=786 335 | To: ;tag=087js 336 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 337 | CSeq: 3 BYE 338 | Content-Length: 0 340 The BYE is then acknowledged by the XMPP-to-SIP gateway. 342 Example 9: Gateway acknowledges termination (F15) 344 | SIP/2.0 200 OK 345 | From: ;tag=786 346 | To: ;tag=087js 347 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 348 | CSeq: 3 BYE 349 | Content-Length: 0 351 Because there is no formal session on the XMPP side, there is no 352 corresponding communication from the gateway to the XMPP user. 353 However, it is reasonable for the gateway to send a "gone" chat state 354 notification [XEP-0085], as described under Section 6.1. 356 In addition, there is no explicit method defined in [RFC6121] for an 357 XMPP user to formally terminate a chat session, so a gateway would 358 need to listen for a "gone" chat state notification from the XMPP 359 user or institute a timer that considers the XMPP informal chat 360 session to be ended after some amount of time has elapsed. 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 specified in 422 [I-D.ietf-stox-im]. 424 The protocol flow begins when Romeo starts a chat session with 425 Juliet. 427 Example 10: Romeo starts chat session (F17) 429 | INVITE sip:juliet@example.com SIP/2.0 430 | From: 431 | To: 432 | Contact: ;gr=dr4hcr0st3lup4c 433 | Subject: Open chat with Romeo? 434 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 435 | CSeq: 1 INVITE 436 | Content-Type: application/sdp 437 | 438 | c=IN IP4 s2x.example.net 439 | m=message 7313 TCP/MSRP * 440 | a=accept-types:text/plain 441 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 443 Upon receiving the INVITE, the SIP (MSRP) server needs to determine 444 the identity of the domain portion of the Request-URI or To header, 445 which it does by following the procedures explained in Section 5 of 446 [RFC7247]. If the domain is an XMPP domain, the SIP server will hand 447 off the INVITE to an associated MSRP-to-XMPP gateway or connection 448 manager that natively communicates with XMPP servers. 450 Example 11: Gateway accepts session on Juliet's behalf (F19) 452 | SIP/2.0 200 OK 453 | From: ;gr=dr4hcr0st3lup4c 454 | To: 455 | Contact: ;gr=yn0cl4bnw0yr3vym 456 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 457 | CSeq: 1 INVITE 458 | Content-Type: application/sdp 459 | 460 | c=IN IP4 x2s.example.com 461 | m=message 8763 TCP/MSRP * 462 | a=accept-types:text/plain 463 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 465 Example 12: Romeo sends ACK (F21) 467 | ACK sip:juliet@example.com SIP/2.0 468 | To: ;gr=yn0cl4bnw0yr3vym 469 | From: 470 | Contact: ;gr=dr4hcr0st3lup4c 471 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 472 | CSeq: 2 ACK 473 Example 13: Romeo sends message (F23) 475 | MSRP ad49kswow SEND 476 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 477 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 478 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 479 | Byte-Range: 1-32/32 480 | Failure-Report: no 481 | Content-Type: text/plain 482 | 483 | I take thee at thy word ... 484 | -------ad49kswow$ 486 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24) 488 | 492 | F6989A8C-DE8A-4E21-8E07-F0898304796F 493 | I take thee at thy word ... 494 | 496 Example 15: Juliet sends reply (F26) 498 | 502 | 29377446-0CBB-4296-8958-590D79094C50 503 | What man art thou ...? 504 | 506 Example 16: Gateway maps XMPP message to MSRP (F28) 508 | MSRP ms53b7z9 SEND 509 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 510 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 511 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 512 | Byte-Range: 1-25/25 513 | Failure-Report: no 514 | Content-Type: text/plain 515 | 516 | What man art thou ...? 517 | -------ms53b7z9$ 518 Example 17: Romeo terminates chat session (F29) 520 | BYE juliet@example.com sip: SIP/2.0 521 | To: ;gr=yn0cl4bnw0yr3vym 522 | From: 523 | Contact: ;gr=dr4hcr0st3lup4c 524 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 525 | CSeq: 3 BYE 526 | Content-Length: 0 528 Example 18: Gateway acknowledges termination of session on behalf of 529 Juliet (F31) 531 | SIP/2.0 200 OK 532 | To: ;gr=yn0cl4bnw0yr3vym 533 | From: 534 | Contact: ;gr=dr4hcr0st3lup4c 535 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 536 | CSeq: 3 BYE 538 6. Composing Events 540 Both XMPP and MSRP enable a client to receive notifications when a 541 person's conversation partner is composing an instant message within 542 the context of a chat session. 544 For XMPP, the Chat State Notifications specification [XEP-0085] 545 defines five states: active, inactive, gone, composing, and paused. 546 Some of these states are related to the act of message composition 547 (composing, paused), whereas others are related to the sender's 548 involvement with the chat session (active, inactive, gone). Note 549 that the "gone" chat state is not to be confused with the 550 stanza error condition defined in [RFC6120]. 552 For MSRP (and SIP/SIMPLE in general), the Indication of Message 553 Composition for Instant Messaging specification [RFC3994] defines two 554 states: idle and active. Here the idle state indicates that the 555 sender is not actively composing a message, and the active state 556 indicates that the sender is indeed actively composing a message (the 557 sending client simply toggles between the two states, changing to 558 active if the user is actively composing a message and changing to 559 idle if the user is no longer actively composing a message). 561 Because the XEP-0085 states can represent information that is not 562 captured in RFC 3994, gateways can either (a) map only the composing- 563 related states or (b) map all the XEP-0085 states. 565 The following mappings are suggested. 567 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states 569 +-------------------+--------------------+ 570 | isComposing Event | Chat State | 571 +-------------------+--------------------+ 572 | active | composing | 573 | idle | active | 574 +-------------------+--------------------+ 576 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events 578 +-------------------+--------------------+ 579 | Chat State | isComposing Event | 580 +-------------------+--------------------+ 581 | active | idle | 582 | inactive | idle | 583 | gone | [none, see note] | 584 | composing | active | 585 | paused | idle | 586 +-------------------+--------------------+ 588 6.1. Use of the Gone Chat State 590 Although there is no direct mapping for the "gone" chat state to an 591 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP 592 gateway can serve as a trigger for terminating the formal chat 593 session within MSRP, i.e., for sending a SIP BYE for the session from 594 the XMPP-to-MSRP gateway to the SIP user. The following examples 595 illustrate this indirect mapping (which would occur after step F14 in 596 Figure 1). 598 Example 19: Juliet sends gone chat state 600 | 604 | 29377446-0CBB-4296-8958-590D79094C50 605 | 606 | 607 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE 609 | BYE romeo@example.net sip: SIP/2.0 610 | From: ;tag=786 611 | To: ;tag=087js 612 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 613 | CSeq: 3 BYE 614 | Content-Length: 0 616 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway 617 can serve as a trigger for sending a "gone" chat state notification 618 to the XMPP user. The following examples illustrate this indirect 619 mapping (which would occur after step F30 in Figure 2). 621 Example 21: Romeo terminates chat session 623 | BYE juliet@example.com sip: SIP/2.0 624 | To: ;gr=yn0cl4bnw0yr3vym 625 | From: 626 | Contact: ;gr=dr4hcr0st3lup4c 627 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 628 | CSeq: 3 BYE 629 | Content-Length: 0 631 Example 22: MSRP-to-XMPP gateway generates gone chat state 633 | 637 | F6989A8C-DE8A-4E21-8E07-F0898304796F 638 | 639 | 641 To enable these uses, gateways that support chat state notifications 642 MUST support the "gone" state (which is merely recommended, not 643 required, by [XEP-0085]). 645 It is also reasonable for gateways to implement timers that 646 automatically trigger a "gone" chat state if the XMPP user has not 647 sent a message within the "session" for a given amount of time. 649 7. Delivery Reports 651 Both XMPP and MSRP enable a client to receive notifications when a 652 message has been received by the intended recipient. 654 For XMPP, the Message Receipts specification [XEP-0184] defines a 655 method and XML namespace for requesting and returning indications 656 that a message has been received by a client controlled by the 657 intended recipient. 659 For MSRP, a native reporting feature is included, in the form of 660 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 662 An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report 664 header field with a value of "yes", and an XMPP Message Receipts 665 element of is to be mapped to 666 an MSRP REPORT request. 668 A Success-Report header field with a value of "yes" in an MSRP SEND 669 request is to be mapped to an XMPP Message Receipts element of 670 , and an MSRP REPORT request is 671 to be mapped to an XMPP message containing only a Message Receipts 672 element of . 674 Because the XMPP Message Receipts specification does not support 675 failure reports, there is no mapping for the MSRP Failure-Report 676 header field and gateways SHOULD set that header field to "no". 678 Examples follow. 680 First, the XMPP user sends a message containing a request for 681 delivery notification. 683 Example 23: Juliet sends XMPP message with receipt request 685 | 689 | 29377446-0CBB-4296-8958-590D79094C50 690 | What man art thou ...? 691 | 692 | 693 Example 24: Gateway maps XMPP message to MSRP 695 | MSRP bf9m36d5 SEND 696 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 697 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 698 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 699 | Byte-Range: 1-25/25 700 | Success-Report: yes 701 | Failure-Report: no 702 | Content-Type: text/plain 703 | 704 | What man art thou ...? 705 | -------bf9m36d5$ 707 Next, the recipient returns a report. 709 Example 25: Romeo returns MSRP receipt 711 | MSRP hx74g336 REPORT 712 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 713 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 714 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 715 | Byte-Range: 1-106/106 716 | Status: 000 200 OK 717 | -------hx74g336$ 719 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP 721 | 724 | 725 | 727 8. Message Size 729 Unlike page-mode messaging [RFC3428] (which specifies that the size 730 of a MESSAGE request is not allowed to exceed 1300 bytes), session- 731 mode messaging [RFC4975] can be used to send larger messages. MSRP 732 includes a chunking mechanism such that larger messages can be broken 733 up into multiple MSRP SEND requests. Because the MSRP gateway at an 734 XMPP service acts as an MSRP endpoint, it is responsible for 735 receiving chunked messages and reconstructing them into a single 736 message for delivery toward the XMPP recipient. (Naturally, 737 implementations need to be careful about accepting very large 738 messages; see Section 14.5 of [RFC4975].) 739 Although there is no hard limit on the size of an XMPP stanza, in 740 practice most XMPP services (at least on the public Internet) are 741 configured with a maximum stanza size in order to help prevent denial 742 of service attacks. As specified in Section 13.12 of [RFC6120], this 743 maximum is not allowed to be less than 10,000 bytes. 745 The administrators of an XMPP service need to ensure that the 746 associated MSRP gateway is configured with the same or smaller 747 maximum MSRP message size as the maximum XMPP stanza size; this 748 enables the gateway to return an appropriate value for the SDP "max- 749 size" attribute (see Section 8.6 of [RFC4975]) and to properly handle 750 incoming messages larger than the configured limits. 752 If an MSRP-to-XMPP gateway implementation receives an MSRP message 753 that exceeds its configured limit as just described, it MUST return 754 an MSRP 413 error (e.g., in response to the first SEND request whose 755 Byte-Range header field indicates a byte total exceeding the limit). 757 9. Internationalization Considerations 759 Relevant discussion of internationalized text in messages can be 760 found in [I-D.ietf-stox-im]. 762 10. IANA Considerations 764 This document requests no actions of IANA. 766 11. Security Considerations 768 Detailed security considerations for instant messaging protocols are 769 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 770 when SIP is used to negotiate MSRP sessions), and for XMPP-based 771 instant messaging in [RFC6121] (see also [RFC6120]). The security 772 considerations provided in [RFC7247] also apply. 774 This document specifies methods for exchanging instant messages 775 through a gateway that translates between SIP/MSRP and XMPP. Such a 776 gateway MUST be compliant with the minimum security requirements of 777 the textual chat protocols for which it translates (i.e., MSRP and 778 XMPP). The addition of gateways to the security model of instant 779 messaging specified in [RFC2779] introduces some new risks. In 780 particular, end-to-end security properties (especially 781 confidentiality and integrity) between instant messaging clients that 782 interface through an MSRP-XMPP gateway can be provided only if common 783 formats are supported. Although specification of those common 784 formats is out of scope for this document, for instant messages it is 785 possible to use [RFC3862] (see also [RFC3923]). 787 12. References 789 12.1. Normative References 791 [I-D.ietf-stox-im] 792 Saint-Andre, P., Houri, A., and J. Hildebrand, 793 "Interworking between the Session Initiation Protocol 794 (SIP) and the Extensible Messaging and Presence Protocol 795 (XMPP): Instant Messaging", draft-ietf-stox-im-12 (work in 796 progress), February 2015. 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", BCP 14, RFC 2119, March 1997. 801 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 802 A., Peterson, J., Sparks, R., Handley, M., and E. 803 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 804 June 2002. 806 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 807 Messaging (CPIM): Message Format", RFC 3862, August 2004. 809 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 810 Instant Messaging", RFC 3994, January 2005. 812 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 813 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 815 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 816 Protocol (XMPP): Core", RFC 6120, March 2011. 818 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 819 Protocol (XMPP): Instant Messaging and Presence", RFC 820 6121, March 2011. 822 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, 823 "Interworking between the Session Initiation Protocol 824 (SIP) and the Extensible Messaging and Presence Protocol 825 (XMPP): Architecture, Addresses, and Error Handling", RFC 826 7247, May 2014. 828 [XEP-0085] 829 Saint-Andre, P. and D. Smith, "Chat State Notifications", 830 XSF XEP 0085, September 2009. 832 [XEP-0184] 833 Saint-Andre, P. and J. Hildebrand, "Message Delivery 834 Receipts", XSF XEP 0184, March 2011. 836 12.2. Informative References 838 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 839 / Presence Protocol Requirements", RFC 2779, February 840 2000. 842 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 843 and D. Gurle, "Session Initiation Protocol (SIP) Extension 844 for Instant Messaging", RFC 3428, December 2002. 846 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 847 for the Extensible Messaging and Presence Protocol 848 (XMPP)", RFC 3923, October 2004. 850 Appendix A. Acknowledgements 852 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an 853 early version of this document. 855 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, 856 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for 857 their feedback. 859 The authors gratefully acknowledge the assistance of Markus Isomaki 860 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 861 and Alissa Cooper as the sponsoring Area Directors. 863 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 864 employing him during his work on earlier versions of this document. 866 Authors' Addresses 868 Peter Saint-Andre 869 &yet 871 Email: peter@andyet.com 872 URI: https://andyet.com/ 874 Salvatore Loreto 875 Ericsson 876 Hirsalantie 11 877 Jorvas 02420 878 Finland 880 Email: Salvatore.Loreto@ericsson.com