idnits 2.17.1 draft-ietf-stox-chat-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3340 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' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 6, 2015 Ericsson 6 March 5, 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-11 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 September 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. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 17 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 negotiated when using 102 SIP). By contrast, a one-to-one chat "session" in XMPP is an 103 informal construct and is not formally negotiated: a user simply 104 sends a message of type "chat" to a contact, the contact then replies 105 to the message, and the sum total of such messages exchanged during a 106 defined period of time is considered to be a chat session (ideally 107 tied together using an XMPP element as described in 108 Section 5.1 of [RFC6121]). To overcome the disparity between these 109 approaches, a gateway that wishes to map between SIP/MSRP and XMPP 110 for one-to-one chat sessions needs to maintain some additional state, 111 as described below. 113 2. Intended Audience 115 The documents in this series are intended for use by software 116 developers who have an existing system based on one of these 117 technologies (e.g., SIP), and would like to enable communication from 118 that existing system to systems based on the other technology (e.g., 119 XMPP). We assume that readers are familiar with the core 120 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the 121 base document for this series [RFC7247], and with the following chat- 122 related specifications: 124 o The Message Session Relay Protocol (MSRP) [RFC4975] 126 o Extensible Messaging and Presence Protocol: Instant Messaging and 127 Presence [RFC6121] 129 o Indication of Message Composition for Instant Messaging [RFC3994] 131 o Chat State Notifications [XEP-0085] 133 Note well that not all protocol-compliant messages are shown (such as 134 SIP 100 TRYING messages), in order to focus the reader on the 135 essential aspects of the protocol flows. 137 3. Terminology 139 A number of terms used here are explained in [RFC3261], [RFC4975], 140 [RFC6120], and [RFC6121]. 142 In flow diagrams, SIP/MSRP traffic is shown using arrows such as 143 "***>" whereas XMPP traffic is shown using arrows such as "...>". 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119]. 150 4. XMPP to MSRP 152 In XMPP, the "informal session" approach is to simply send someone a 153 of type "chat" without starting any session negotiation 154 ahead of time (as described in [RFC6121]). The XMPP "informal 155 session" approach maps very well into a SIP MESSAGE request, as 156 described in [RFC7247]. However, the XMPP informal session approach 157 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains 158 additional state. The order of events is as follows. 160 XMPP XMPP XMPP-to-MSRP SIP SIP 161 User Server Gateway Server User 162 | | | | | 163 | (F1) XMPP | | | | 164 | message | | | | 165 |..............>| | | | 166 | | (F2) XMPP | | | 167 | | message | | | 168 | |..............>| | | 169 | | | (F3) SIP | | 170 | | | INVITE | | 171 | | |**************>| | 172 | | | | (F4) SIP | 173 | | | | INVITE | 174 | | | |**************>| 175 | | | | (F5) SIP | 176 | | | | 200 OK | 177 | | | |<**************| 178 | | | (F6) SIP | | 179 | | | 200 OK | | 180 | | |<**************| | 181 | | | (F7) SIP ACK | | 182 | | |**************>| | 183 | | | | (F8) SIP ACK | 184 | | | |**************>| 185 | | | (F9) MSRP SEND | 186 | | |******************************>| 187 . . . . . 188 . . . . . 189 | | | (F10) MSRP SEND | 190 | | |<******************************| 191 | | (F11) XMPP | | | 192 | | message | | | 193 | |<..............| | | 194 | (F12) XMPP | | | | 195 | message | | | | 196 |<..............| | | | 197 . . . . . 198 . . . . . 199 | | | | (F13) SIP BYE | 200 | | | |<**************| 201 | | | (F14) SIP BYE | | 202 | | |<**************| | 203 | | | (F15) SIP | | 204 | | | 200 OK | | 205 | | |**************>| | 206 | | | | (F16) SIP | 207 | | | | 200 OK | 208 | | | |**************>| 210 Figure 1: XMPP to MSRP Order of Events 212 The mapping of XMPP syntax to SIP syntax MUST be as specified in 213 [I-D.ietf-stox-im]. 215 First the XMPP user would generate an XMPP chat message. 217 Example 1: Juliet sends XMPP message (F1) 219 | 223 | 29377446-0CBB-4296-8958-590D79094C50 224 | Art thou not Romeo, and a Montague? 225 | 227 Upon receiving such a message stanza, the XMPP server needs to 228 determine the identity of the domainpart in the 'to' address, which 229 it does by following the procedures explained in Section 5 of 230 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand 231 off the message stanza to an XMPP-to-SIP gateway or connection 232 manager that natively communicates with MSRP-aware SIP servers. 234 The XMPP-to-SIP gateway at the XMPP server would then initiate an 235 MSRP session with Romeo on Juliet's behalf (since there is no 236 reliable way for the gateway to determine whether Romeo's client 237 supports MSRP, if that is not the case then MSRP session initiation 238 might result in an error). 240 Example 2: Gateway starts SIP session on behalf of Juliet (F3) 242 | INVITE sip:romeo@example.net SIP/2.0 243 | To: 244 | From: 245 | Contact: ;gr=yn0cl4bnw0yr3vym 246 | Subject: Open chat with Juliet? 247 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 248 | CSeq: 1 INVITE 249 | Content-Type: application/sdp 250 | 251 | c=IN IP4 x2s.example.com 252 | m=message 7654 TCP/MSRP * 253 | a=accept-types:text/plain 254 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 256 Here we assume that Romeo's client supports MSRP and that Romeo 257 accepts the MSRP session request. 259 Example 3: Romeo accepts session request (F5) 261 | SIP/2.0 200 OK 262 | From: 263 | To: 264 | Contact: ;gr=dr4hcr0st3lup4c 265 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 266 | CSeq: 1 INVITE 267 | Content-Type: application/sdp 268 | 269 | c=IN IP4 s2x.example.net 270 | m=message 12763 TCP/MSRP * 271 | a=accept-types:text/plain 272 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 274 The XMPP-to-SIP gateway then acknowledges the session acceptance on 275 behalf of Juliet. 277 Example 4: Gateway sends ACK to Romeo (F7) 279 | ACK sip:juliet@example.com SIP/2.0 280 | To: ;gr=dr4hcr0st3lup4c 281 | From: 282 | Contact: ;gr=yn0cl4bnw0yr3vym 283 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 284 | CSeq: 2 ACK 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=786 336 | To: ;tag=087js 337 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 338 | CSeq: 3 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: 3 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 In addition, there is no explicit method defined in [RFC6121] for an 358 XMPP user to formally terminate a chat session, so a gateway would 359 need to listen for a "gone" chat state notification from the XMPP 360 user or institute a timer that considers the XMPP informal chat 361 session to be ended after some amount of time has elapsed ([XEP-0085] 362 suggests generating a "gone" chat state if a user has not interacted 363 with the chat session interface, system, or device for a relatively 364 long period of time, e.g., 10 minutes). 366 5. MSRP to XMPP 368 When an MSRP client sends messages through a gateway to an XMPP 369 client, the order of events is as follows. 371 SIP SIP MSRP-to-XMPP XMPP XMPP 372 User Server Gateway Server User 373 | | | | | 374 | (F17) SIP | | | | 375 | INVITE | | | | 376 |**************>| | | | 377 | | (F18) SIP | | | 378 | | INVITE | | | 379 | |**************>| | | 380 | | (F19) SIP | | | 381 | | 200 OK | | | 382 | |<**************| | | 383 | (F20) SIP | | | | 384 | 200 OK | | | | 385 |<**************| | | | 386 | (F21) SIP ACK | | | | 387 |**************>| | | | 388 | | (F22) SIP ACK | | | 389 | |**************>| | | 390 | (F23) MSRP SEND | | | 391 |******************************>| | | 392 | | | (F24) XMPP | | 393 | | | message | | 394 | | |..............>| | 395 | | | | (F25) XMPP | 396 | | | | message | 397 | | | |..............>| 398 . . . . . 399 . . . . . 400 | | | | (F26) XMPP | 401 | | | | message | 402 | | | |<..............| 403 | | | (F27) XMPP | | 404 | | | message | | 405 | | |<..............| | 406 | (F28) MSRP SEND | | | 407 |<******************************| | | 408 . . . . . 409 . . . . . 410 | | | | | 411 | | | | | 412 | (F29) SIP BYE | | | | 413 |**************>| | | | 414 | | (F30) SIP BYE | | | 415 | |**************>| | | 416 | | (F31) SIP | | | 417 | | 200 OK | | | 418 | |<**************| | | 419 | (F32) SIP | | | | 420 | 200 OK | | | | 421 |<**************| | | | 423 Figure 2: MSRP to XMPP Order of Events 425 The mapping of SIP syntax to XMPP syntax MUST be as specified in 426 [I-D.ietf-stox-im]. 428 The protocol flow begins when Romeo starts a chat session with 429 Juliet. 431 Example 10: Romeo starts chat session (F17) 433 | INVITE sip:juliet@example.com SIP/2.0 434 | From: 435 | To: 436 | Contact: ;gr=dr4hcr0st3lup4c 437 | Subject: Open chat with Romeo? 438 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 439 | CSeq: 1 INVITE 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 | From: ;gr=dr4hcr0st3lup4c 458 | To: 459 | Contact: ;gr=yn0cl4bnw0yr3vym 460 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 461 | CSeq: 1 INVITE 462 | Content-Type: application/sdp 463 | 464 | c=IN IP4 x2s.example.com 465 | m=message 8763 TCP/MSRP * 466 | a=accept-types:text/plain 467 | 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=yn0cl4bnw0yr3vym 472 | From: 473 | Contact: ;gr=dr4hcr0st3lup4c 474 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 475 | CSeq: 2 ACK 477 Example 13: Romeo sends message (F23) 479 | MSRP ad49kswow SEND 480 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 481 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 482 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 483 | Byte-Range: 1-32/32 484 | Failure-Report: no 485 | Content-Type: text/plain 486 | 487 | I take thee at thy word ... 488 | -------ad49kswow$ 490 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24) 492 | 496 | F6989A8C-DE8A-4E21-8E07-F0898304796F 497 | I take thee at thy word ... 498 | 500 Example 15: Juliet sends reply (F26) 502 | 506 | 29377446-0CBB-4296-8958-590D79094C50 507 | What man art thou ...? 508 | 509 Example 16: Gateway maps XMPP message to MSRP (F28) 511 | MSRP ms53b7z9 SEND 512 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 513 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 514 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 515 | Byte-Range: 1-25/25 516 | Failure-Report: no 517 | Content-Type: text/plain 518 | 519 | What man art thou ...? 520 | -------ms53b7z9$ 522 Example 17: Romeo terminates chat session (F29) 524 | BYE juliet@example.com sip: SIP/2.0 525 | To: ;gr=yn0cl4bnw0yr3vym 526 | From: 527 | Contact: ;gr=dr4hcr0st3lup4c 528 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 529 | CSeq: 3 BYE 530 | Content-Length: 0 532 Example 18: Gateway acknowledges termination of session on behalf of 533 Juliet (F31) 535 | SIP/2.0 200 OK 536 | To: ;gr=yn0cl4bnw0yr3vym 537 | From: 538 | Contact: ;gr=dr4hcr0st3lup4c 539 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 540 | CSeq: 3 BYE 542 6. Composing Events 544 Both XMPP and MSRP enable a client to receive notifications when a 545 person's conversation partner is composing an instant message within 546 the context of a chat session. 548 For XMPP, the Chat State Notifications specification [XEP-0085] 549 defines five states: active, inactive, gone, composing, and paused. 550 Some of these states are related to the act of message composition 551 (composing, paused), whereas others are related to the sender's 552 involvement with the chat session (active, inactive, gone). Note 553 that the "gone" chat state is not to be confused with the 554 stanza error condition defined in [RFC6120]. 556 For MSRP (and SIP/SIMPLE in general), the Indication of Message 557 Composition for Instant Messaging specification [RFC3994] defines two 558 states: idle and active. Here the idle state indicates that the 559 sender is not actively composing a message, and the active state 560 indicates that the sender is indeed actively composing a message (the 561 sending client simply toggles between the two states). 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 S.6.1] | 586 | composing | active | 587 | paused | idle | 588 +-------------------+--------------------+ 590 The XMPP Chat State Notifications specification [XEP-0085] allows the 591 sending of "standalone notifications" outside the context of a 592 message, theoretically even before any messages are exchanged; 593 although a gateway could thus send an notification to the 594 XMPP user when the SIP user accepts or initiates a chat session 595 (i.e., after F6 in Section 4 or after F22 in Section 5), this usage 596 might be unexpected by XMPP clients as a way to signal the beginning 597 of an informal chat session. 599 6.1. Use of the Gone Chat State 601 Although there is no direct mapping for the "gone" chat state to an 602 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP 603 gateway can serve as a trigger for terminating the formal chat 604 session within MSRP, i.e., for sending a SIP BYE for the session from 605 the XMPP-to-MSRP gateway to the SIP user. The following examples 606 illustrate this indirect mapping (which would occur after step F14 in 607 Figure 1). 609 Example 19: Juliet sends gone chat state 611 | 615 | 29377446-0CBB-4296-8958-590D79094C50 616 | 617 | 619 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE 621 | BYE romeo@example.net sip: SIP/2.0 622 | From: ;tag=786 623 | To: ;tag=087js 624 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 625 | CSeq: 3 BYE 626 | Content-Length: 0 628 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway 629 can serve as a trigger for sending a "gone" chat state notification 630 to the XMPP user. The following examples illustrate this indirect 631 mapping (which would occur after step F30 in Figure 2). 633 Example 21: Romeo terminates chat session 635 | BYE juliet@example.com sip: SIP/2.0 636 | To: ;gr=yn0cl4bnw0yr3vym 637 | From: 638 | Contact: ;gr=dr4hcr0st3lup4c 639 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 640 | CSeq: 3 BYE 641 | Content-Length: 0 643 Example 22: MSRP-to-XMPP gateway generates gone chat state 645 | 649 | F6989A8C-DE8A-4E21-8E07-F0898304796F 650 | 651 | 652 To enable these uses, gateways that support chat state notifications 653 MUST support the "gone" state (which is merely recommended, not 654 required, by [XEP-0085]). 656 It is also reasonable for gateways to implement timers that 657 automatically trigger a "gone" chat state if the XMPP user has not 658 sent a message within the "session" for a given amount of time 659 ([XEP-0085] suggests generating a "gone" chat state if a user has not 660 interacted with the chat session interface, system, or device for a 661 relatively long period of time, e.g., 10 minutes). 663 7. Delivery Reports 665 Both XMPP and MSRP enable a client to receive notifications when a 666 message has been received by the intended recipient. 668 For XMPP, the Message Receipts specification [XEP-0184] defines a 669 method and XML namespace for requesting and returning indications 670 that a message has been received by a client controlled by the 671 intended recipient. 673 For MSRP, a native reporting feature is included, in the form of 674 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 676 An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report 678 header field with a value of "yes", and an XMPP Message Receipts 679 element of is to be mapped to 680 an MSRP REPORT request. 682 A Success-Report header field with a value of "yes" in an MSRP SEND 683 request is to be mapped to an XMPP Message Receipts element of 684 , and an MSRP REPORT request is 685 to be mapped to an XMPP message containing only a Message Receipts 686 element of . 688 Because the XMPP Message Receipts specification does not support 689 failure reports, there is no mapping for the MSRP Failure-Report 690 header field and gateways SHOULD set that header field to "no". 692 Examples follow. 694 First, the XMPP user sends a message containing a request for 695 delivery notification. 697 Example 23: Juliet sends XMPP message with receipt request 699 | 703 | 29377446-0CBB-4296-8958-590D79094C50 704 | What man art thou ...? 705 | 706 | 708 Example 24: Gateway maps XMPP message to MSRP 710 | MSRP bf9m36d5 SEND 711 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 712 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 713 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 714 | Byte-Range: 1-25/25 715 | Success-Report: yes 716 | Failure-Report: no 717 | Content-Type: text/plain 718 | 719 | What man art thou ...? 720 | -------bf9m36d5$ 722 Next, the recipient returns a report. 724 Example 25: Romeo returns MSRP receipt 726 | MSRP hx74g336 REPORT 727 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 728 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 729 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 730 | Byte-Range: 1-106/106 731 | Status: 000 200 OK 732 | -------hx74g336$ 734 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP 736 | 739 | 740 | 742 8. Message Size 744 Unlike page-mode messaging [RFC3428] (which specifies that the size 745 of a MESSAGE request is not allowed to exceed 1300 bytes), session- 746 mode messaging [RFC4975] can be used to send larger messages. MSRP 747 includes a chunking mechanism such that larger messages can be broken 748 up into multiple MSRP SEND requests. Because the MSRP gateway at an 749 XMPP service acts as an MSRP endpoint, it is responsible for 750 receiving chunked messages and reconstructing them into a single 751 message for delivery toward the XMPP recipient. (Naturally, 752 implementations need to be careful about accepting very large 753 messages; see Section 14.5 of [RFC4975].) 755 Although there is no hard limit on the size of an XMPP stanza, in 756 practice most XMPP services (at least on the public Internet) are 757 configured with a maximum stanza size in order to help prevent denial 758 of service attacks. As specified in Section 13.12 of [RFC6120], this 759 maximum is not allowed to be less than 10,000 bytes. 761 The administrators of an XMPP service need to ensure that the 762 associated MSRP gateway is configured with the same or smaller 763 maximum MSRP message size as the maximum XMPP stanza size; this 764 enables the gateway to return an appropriate value for the SDP "max- 765 size" attribute (see Section 8.6 of [RFC4975]) and to properly handle 766 incoming messages larger than the configured limits. 768 If an MSRP-to-XMPP gateway implementation receives an MSRP message 769 that exceeds its configured limit as just described, it MUST return 770 an MSRP 413 error (e.g., in response to the first SEND request whose 771 Byte-Range header field indicates a byte total exceeding the limit). 773 9. Internationalization Considerations 775 Relevant discussion of internationalized text in messages can be 776 found in [I-D.ietf-stox-im]. 778 10. IANA Considerations 780 This document requests no actions of IANA. 782 11. Security Considerations 784 Detailed security considerations for instant messaging protocols are 785 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 786 when SIP is used to negotiate MSRP sessions), and for XMPP-based 787 instant messaging in [RFC6121] (see also [RFC6120]). The security 788 considerations provided in [RFC7247] also apply. 790 Considerations for end-to-end encryption of instant messages are 791 provided in [I-D.ietf-stox-im]. 793 12. References 795 12.1. Normative References 797 [I-D.ietf-stox-im] 798 Saint-Andre, P., Houri, A., and J. Hildebrand, 799 "Interworking between the Session Initiation Protocol 800 (SIP) and the Extensible Messaging and Presence Protocol 801 (XMPP): Instant Messaging", draft-ietf-stox-im-13 (work in 802 progress), March 2015. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 808 A., Peterson, J., Sparks, R., Handley, M., and E. 809 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 810 June 2002. 812 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 813 Instant Messaging", RFC 3994, January 2005. 815 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 816 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 818 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 819 Protocol (XMPP): Core", RFC 6120, March 2011. 821 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 822 Protocol (XMPP): Instant Messaging and Presence", RFC 823 6121, March 2011. 825 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, 826 "Interworking between the Session Initiation Protocol 827 (SIP) and the Extensible Messaging and Presence Protocol 828 (XMPP): Architecture, Addresses, and Error Handling", RFC 829 7247, May 2014. 831 [XEP-0085] 832 Saint-Andre, P. and D. Smith, "Chat State Notifications", 833 XSF XEP 0085, September 2009. 835 [XEP-0184] 836 Saint-Andre, P. and J. Hildebrand, "Message Delivery 837 Receipts", XSF XEP 0184, March 2011. 839 12.2. Informative References 841 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 842 / Presence Protocol Requirements", RFC 2779, February 843 2000. 845 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 846 and D. Gurle, "Session Initiation Protocol (SIP) Extension 847 for Instant Messaging", RFC 3428, December 2002. 849 Appendix A. Acknowledgements 851 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an 852 early version of this document. 854 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, 855 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for 856 their feedback. 858 Stephen Farrell, Brian Haberman, Joel Jaeggli, Barry Leiba, Kathleen 859 Moriarty, and Pete Resnick provided helpful input during IESG review. 861 The authors gratefully acknowledge the assistance of Markus Isomaki 862 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 863 and Alissa Cooper as the sponsoring Area Directors. 865 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 866 employing him during his work on earlier versions of this document. 868 Authors' Addresses 870 Peter Saint-Andre 871 &yet 873 Email: peter@andyet.com 874 URI: https://andyet.com/ 876 Salvatore Loreto 877 Ericsson 878 Hirsalantie 11 879 Jorvas 02420 880 Finland 882 Email: Salvatore.Loreto@ericsson.com