idnits 2.17.1 draft-ietf-stox-chat-06.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 11, 2014) is 3698 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: September 12, 2014 Ericsson 6 March 11, 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-06 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 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 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 [I-D.ietf-stox-core], including mapping of addresses and 80 error conditions. This document specifies mappings for one-to-one 81 text 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 [I-D.ietf-stox-core], and with the 120 following chat-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 [I-D.ietf-stox-core]. However, the XMPP informal 151 session approach can also be mapped to MSRP if the XMPP-to-SIP 152 gateway maintains additional state. 154 The order of events is as follows. 156 XMPP XMPP XMPP-to-SIP SIP-to-XMPP SIP SIP 157 User Server Gateway Gateway Server User 158 | | | | | | 159 | (F1) XMPP | | | | | 160 | message | | | | | 161 |..........>| | | | | 162 | | (F2) XMPP | | | | 163 | | message | | | | 164 | |...........>| | | | 165 | | | (F3) SIP INVITE | | 166 | | |**************************>| | 167 | | | | | (F4) SIP | 168 | | | | | INVITE | 169 | | | | |*********>| 170 | | | | | (F5) SIP | 171 | | | | | 200 OK | 172 | | | | |<*********| 173 | | | | (F6) SIP | | 174 | | | | 200 OK | | 175 | | | |<***********| | 176 | | | | (F7) SIP | | 177 | | | | ACK | | 178 | | | |***********>| | 179 | | | | (F8) MSRP | | 180 | | | | SEND | | 181 | | | |***********>| | 182 | | | | | (F9) SIP | 183 | | | | | ACK | 184 | | | | |*********>| 185 | | | | |(F10) MSRP| 186 | | | | | SEND | 187 | | | | |*********>| 188 . . . . . . 189 . . . . . . 190 | | | | |(F11) MSRP| 191 | | | | | SEND | 192 | | | | |<*********| 193 | | | | (F12) MSRP | | 194 | | | | SEND | | 195 | | | |<***********| | 196 | | (F13) XMPP message | | | 197 | |<..........................| | | 198 |(F14) XMPP | | | | | 199 | message | | | | | 200 |<..........| | | | | 201 . . . . . . 202 . . . . . . 203 | | | | |(F15) SIP | 204 | | | | | BYE | 205 | | | | |<*********| 206 | | | | (F16) SIP | | 207 | | | | BYE | | 208 | | | |<***********| | 209 | | | | (F17) SIP | | 210 | | | | 200 OK | | 211 | | | |***********>| | 212 | | | | |(F18) SIP | 213 | | | | | 200 OK | 214 | | | | |*********>| 216 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the 217 following table. (Mappings for several aspects not mentioned here 218 are specified in [I-D.ietf-stox-im].) 220 Table 1: Message syntax mapping from XMPP to SIP 222 +-----------------------------+--------------------------+ 223 | XMPP Element or Attribute | SIP Header or Contents | 224 +-----------------------------+--------------------------+ 225 | | Call-ID | 226 | id | transaction identifier | 227 +-----------------------------+--------------------------+ 229 First the XMPP user would generate an XMPP chat message. 231 Example 1: Juliet sends XMPP message (F1) 233 | 237 | 29377446-0CBB-4296-8958-590D79094C50 238 | Art thou not Romeo, and a Montague? 239 | 240 Upon receiving such a message stanza, the XMPP server needs to 241 determine the identity of the domainpart in the 'to' address, which 242 it does by following the procedures explained in Section 5 of 243 [I-D.ietf-stox-core]. If the domain is a SIP domain, the XMPP server 244 will hand off the message stanza to an XMPP-to-SIP gateway or 245 connection manager that natively communicates with MSRP-aware SIP 246 servers. 248 The XMPP-to-SIP gateway at the XMPP server would then initiate an 249 MSRP session with Romeo on Juliet's behalf (since there is no 250 reliable way for the gateway to determine if Romeo's client supports 251 MSRP, it simply needs to guess). 253 Example 2: Gateway starts SIP session on behalf of Juliet (F3) 255 | INVITE sip:romeo@example.net SIP/2.0 256 | To: 257 | From: 258 | Contact: ;gr=balcony 259 | Subject: Open chat with Juliet? 260 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 261 | Content-Type: application/sdp 262 | 263 | c=IN IP4 x2s.example.com 264 | m=message 7654 TCP/MSRP * 265 | a=accept-types:text/plain 266 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 268 Here we assume that Romeo accepts the MSRP session request. 270 Example 3: Romeo accepts session request (F5) 272 | SIP/2.0 200 OK 273 | To: 274 | From: 275 | Contact: ;gr=orchard 276 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 277 | Content-Type: application/sdp 278 | 279 | c=IN IP4 s2x.example.net 280 | m=message 12763 TCP/MSRP * 281 | a=accept-types:text/plain 282 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 284 The XMPP-to-SIP gateway then acknowledges the session acceptance on 285 behalf of Juliet. 287 Example 4: Gateway sends ACK to Romeo (F7) 289 | ACK sip:juliet@example.com SIP/2.0 290 | To: ;gr=orchard 291 | From: 292 | Contact: ;gr=balcony 293 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 295 The XMPP-to-SIP gateway then transforms the original XMPP chat 296 message into MSRP. 298 Example 5: Gateway maps XMPP message to MSRP (F8) 300 | MSRP a786hjs2 SEND 301 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 302 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 303 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A 304 | Byte-Range: 1-25/25 305 | Content-Type: text/plain 306 | 307 | Art thou not Romeo, and a Montague? 308 | -------a786hjs2$ 310 Romeo can then send a reply using his MSRP client. 312 Example 6: Romeo sends reply (F11) 314 | MSRP di2fs53v SEND 315 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 316 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 317 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA 318 | Byte-Range: 1-25/25 319 | Failure-Report: no 320 | Content-Type: text/plain 321 | 322 | Neither, fair saint, if either thee dislike. 323 | -------di2fs53v$ 325 The SIP-to-XMPP gateway would then transform that message into 326 appropriate XMPP syntax for routing to the intended recipient. 328 Example 7: Gateway maps MSRP message to XMPP (F13) 330 | 334 | 29377446-0CBB-4296-8958-590D79094C50 335 | Neither, fair saint, if either thee dislike. 336 | 338 When the MSRP user wishes to end the chat session, the user's MSRP 339 client sends a SIP BYE. 341 Example 8: Romeo terminates chat session (F15) 343 | BYE juliet@example.com sip: SIP/2.0 344 | From: ;tag=087js 345 | To: ;tag=786 346 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 347 | Cseq: 1 BYE 348 | Content-Length: 0 350 The BYE is then acknowledged by the XMPP-to-SIP gateway. 352 Example 9: Gateway acknowledges termination (F17) 354 | SIP/2.0 200 OK 355 | From: ;tag=786 356 | To: ;tag=087js 357 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 358 | CSeq: 1 BYE 359 | Content-Length: 0 361 5. MSRP to XMPP 363 When an MSRP client sends messages through a gateway to an XMPP 364 client, the order of events is as follows. 366 SIP SIP SIP-to-XMPP XMPP-to-SIP XMPP XMPP 367 User Server Gateway Gateway Server User 368 | | | | | | 369 | (F19) SIP | | | | | 370 | INVITE | | | | | 371 |**********>| | | | | 372 | | (F20) SIP | | | | 373 | | INVITE | | | | 374 | |***********>| | | | 375 | | (F21) SIP | | | | 376 | | 200 OK | | | | 377 | |<***********| | | | 378 | (F22) SIP | | | | | 379 | 200 OK | | | | | 380 |<**********| | | | | 381 | (F23) SIP | | | | | 382 | ACK | | | | | 383 |**********>| | | | | 384 | (F24) MSRP| | | | | 385 | SEND | | | | | 386 |**********>| | | | | 387 | | (F25) SIP | | | | 388 | | ACK | | | | 389 | |***********>| | | | 390 | | (F26) MSRP | | | | 391 | | SEND | | | | 392 | |***********>| | | | 393 | | | (F27) XMPP message | | 394 | | |..........................>| | 395 | | | | | (F28) XMPP| 396 | | | | | message | 397 | | | | |..........>| 398 . . . . . . 399 . . . . . . 400 | | | | | (F29) XMPP| 401 | | | | | message | 402 | | | | |<..........| 403 | | | | (F30) XMPP | | 404 | | | | message | | 405 | | | |<...........| | 406 | | (F31) MSRP SEND | | | 407 | |<**************************| | | 408 | (F32) MSRP| | | | | 409 | SEND | | | | | 410 |<**********| | | | | 411 . . . . . . 412 . . . . . . 413 | | | | | | 414 | | | | | | 415 | (F33) SIP | | | | | 416 | BYE | | | | | 417 |**********>| | | | | 418 | | (F34) SIP | | | | 419 | | BYE | | | | 420 | |***********>| | | | 421 | | (F35) SIP | | | | 422 | | 200 OK | | | | 423 | |<***********| | | | 424 | (F36) SIP | | | | | 425 | 200 OK | | | | | 426 |<**********| | | | | 428 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the 429 following table. (Mappings for several aspects not mentioned here 430 are specified in [I-D.ietf-stox-im].) 432 Table 2: Message syntax mapping from SIP to XMPP 434 +--------------------------+-----------------------------+ 435 | SIP Header or Contents | XMPP Element or Attribute | 436 +--------------------------+-----------------------------+ 437 | Call-ID | | 438 | transaction identifier | id | 439 +--------------------------+-----------------------------+ 441 The protocol flow begins when Romeo starts a chat session with 442 Juliet. 444 Example 10: Romeo starts chat session (F19) 446 | INVITE sip:juliet@example.com SIP/2.0 447 | To: 448 | From: 449 | Contact: ;gr=orchard 450 | Subject: Open chat with Romeo? 451 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 452 | Content-Type: application/sdp 453 | 454 | c=IN IP4 s2x.example.net 455 | m=message 7313 TCP/MSRP * 456 | a=accept-types:text/plain 457 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 459 Upon receiving the INVITE, the SIP (MSRP) server needs to determine 460 the identity of the domain portion of the Request-URI or To header, 461 which it does by following the procedures explained in Section 5 of 462 [I-D.ietf-stox-core]. If the domain is an XMPP domain, the SIP 463 server will hand off the INVITE to an associated SIP-XMPP gateway or 464 connection manager that natively communicates with XMPP servers. 466 Example 11: Gateway accepts session on Juliet's behalf (F21) 468 | SIP/2.0 200 OK 469 | To: ;gr=orchard 470 | From: 471 | Contact: ;gr=balcony 472 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 473 | Content-Type: application/sdp 474 | 475 | c=IN IP4 x2s.example.com 476 | m=message 8763 TCP/MSRP * 477 | a=accept-types:text/plain 478 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 480 Example 12: Romeo sends ACK (F23) 482 | ACK sip:juliet@example.com SIP/2.0 483 | To: ;gr=balcony 484 | From: 485 | Contact: ;gr=orchard 486 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 488 Example 13: Romeo sends message (F24) 490 | MSRP ad49kswow SEND 491 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 492 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 493 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 494 | Byte-Range: 1-32/32 495 | Failure-Report: no 496 | Content-Type: text/plain 497 | 498 | I take thee at thy word ... 499 | -------ad49kswow$ 501 Example 14: SIP-XMPP gateway maps MSRP message to XMPP (F27) 503 | 507 | F6989A8C-DE8A-4E21-8E07-F0898304796F 508 | I take thee at thy word ... 509 | 510 Example 15: Juliet sends reply (F29) 512 | 516 | 29377446-0CBB-4296-8958-590D79094C50 517 | What man art thou ...? 518 | 520 Example 16: Gateway maps XMPP message to MSRP (F31) 522 | MSRP ms53b7z9 SEND 523 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 524 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 525 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 526 | Byte-Range: 1-25/25 527 | Failure-Report: no 528 | Content-Type: text/plain 529 | 530 | What man art thou ...? 531 | -------ms53b7z9$ 533 Example 17: Romeo terminates chat session (F33) 535 | BYE juliet@example.com sip: SIP/2.0 536 | To: ;gr=balcony 537 | From: 538 | Contact: ;gr=orchard 539 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 540 | Cseq: 1 BYE 541 | Content-Length: 0 543 Example 18: Gateway acknowledges termination of session on behalf of 544 Juliet (F35) 546 | SIP/2.0 200 OK 547 | To: ;gr=balcony 548 | From: 549 | Contact: ;gr=orchard 550 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 551 | CSeq: 1 BYE 553 6. Composing Events 555 Both XMPP and MSRP enable a client to receive notifications when a 556 person's conversation partner is composing an instant message within 557 the context of a chat session. 559 For XMPP, the Chat State Notifications specification [XEP-0085] 560 defines five states: active, inactive, gone, composing, and paused. 561 Some of these states are related to the act of message composition 562 (composing, paused), whereas others are related to the sender's 563 involvement with the chat session (active, inactive, gone). 565 For MSRP (and SIP/SIMPLE in general), the Indication of Message 566 Composition for Instant Messaging specification [RFC3994] defines two 567 states: idle and active. Here the idle state indicates that the 568 sender is not actively composing a message, and the active state 569 indicates that the sender is indeed actively composing a message (the 570 sending client simply toggles between the two states, changing to 571 active if the user is actively composing a message and changing to 572 idle if the user is no longer actively composing a message). 574 Because the XEP-0085 states can represent information that is not 575 captured in RFC 3994, gateways can either (a) map only the composing- 576 related states or (b) map all the XEP-0085 states. 578 The following mappings are suggested. 580 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states 582 +-------------------+--------------------+ 583 | isComposing Event | Chat State | 584 +-------------------+--------------------+ 585 | active | composing | 586 | idle | active | 587 +-------------------+--------------------+ 589 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events 591 +-------------------+--------------------+ 592 | Chat State | isComposing Event | 593 +-------------------+--------------------+ 594 | active | idle | 595 | inactive | idle | 596 | gone | [none, see note] | 597 | composing | active | 598 | paused | idle | 599 +-------------------+--------------------+ 601 Although there is no direct mapping for the "gone" chat state (which 602 is not to be confused with the stanza error condition defined 603 in [RFC6120]) to an isComposing event, receipt of the "gone" state 604 can be used as a trigger for terminating the formal chat session 605 within MSRP, i.e., for sending a SIP BYE for the session from the 606 XMPP-SIP gateway to the SIP user. The following examples illustrate 607 this indirect mapping. 609 Example 19: Juliet sends gone chat state 611 | 615 | 29377446-0CBB-4296-8958-590D79094C50 616 | 617 | 619 Example 20: XMPP-SIP 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: 1 BYE 626 | Content-Length: 0 628 7. Delivery Reports 630 Both XMPP and MSRP enable a client to receive notifications when a 631 message has been received by the intended recipient. 633 For XMPP, the Message Receipts specification [XEP-0184] defines a 634 method and XML namespace for requesting and returning indications 635 that a message has been received by a client controlled by the 636 intended recipient. 638 For MSRP, a native reporting feature is included, in the form of 639 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 641 Examples follow. 643 First, the XMPP user sends a message containing a request for 644 delivery notification. 646 Example 21: Juliet sends XMPP message with receipt request 648 | 652 | 29377446-0CBB-4296-8958-590D79094C50 653 | What man art thou ...? 654 | 655 | 657 Example 22: Gateway maps XMPP message to MSRP 659 | MSRP bf9m36d5 SEND 660 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 661 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 662 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 663 | Byte-Range: 1-25/25 664 | Success-Report: yes 665 | Failure-Report: no 666 | Content-Type: text/plain 667 | 668 | What man art thou ...? 669 | -------bf9m36d5$ 671 Next, the recipient returns a report. 673 Example 23: Romeo returns MSRP receipt 675 | MSRP hx74g336 REPORT 676 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 677 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 678 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 679 | Byte-Range: 1-106/106 680 | Status: 000 200 OK 681 | -------hx74g336$ 683 Example 24: SIP-XMPP gateway maps receipt to XMPP 685 | 688 | 689 | 691 8. Internationalization Considerations 693 Relevant discussion of internationalized text in messages can be 694 found in [I-D.ietf-stox-im]. 696 9. IANA Considerations 698 This document requests no actions of IANA. 700 10. Security Considerations 702 Detailed security considerations for instant messaging protocols are 703 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 704 when SIP is used to negotiate MSRP sessions), and for XMPP-based 705 instant messaging in [RFC6121] (see also [RFC6120]). The security 706 considerations provided in [I-D.ietf-stox-core] also apply. 708 This document specifies methods for exchanging instant messages 709 through a gateway that translates between SIP/MSRP and XMPP. Such a 710 gateway MUST be compliant with the minimum security requirements of 711 the textual chat protocols for which it translates (i.e., MSRP and 712 XMPP). The addition of gateways to the security model of instant 713 messaging specified in [RFC2779] introduces some new risks. In 714 particular, end-to-end security properties (especially 715 confidentiality and integrity) between instant messaging clients that 716 interface through an MSRP-XMPP gateway can be provided only if common 717 formats are supported. Specification of those common formats is out 718 of scope for this document, although it is suggested to use [RFC3862] 719 for instant messages. 721 11. References 723 11.1. Normative References 725 [I-D.ietf-stox-core] 726 Saint-Andre, P., Houri, A., and J. Hildebrand, 727 "Interworking between the Session Initiation Protocol 728 (SIP) and the Extensible Messaging and Presence Protocol 729 (XMPP): Core", draft-ietf-stox-core-11 (work in progress), 730 February 2014. 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 736 A., Peterson, J., Sparks, R., Handley, M., and E. 737 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 738 June 2002. 740 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 741 Messaging (CPIM): Message Format", RFC 3862, August 2004. 743 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 744 Instant Messaging", RFC 3994, January 2005. 746 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 747 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 749 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 750 Protocol (XMPP): Core", RFC 6120, March 2011. 752 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 753 Protocol (XMPP): Instant Messaging and Presence", RFC 754 6121, March 2011. 756 [XEP-0085] 757 Saint-Andre, P. and D. Smith, "Chat State Notifications", 758 XSF XEP 0085, September 2009. 760 [XEP-0184] 761 Saint-Andre, P. and J. Hildebrand, "Message Delivery 762 Receipts", XSF XEP 0184, March 2011. 764 11.2. Informative References 766 [I-D.ietf-stox-im] 767 Saint-Andre, P., Houri, A., and J. Hildebrand, 768 "Interworking between the Session Initiation Protocol 769 (SIP) and the Extensible Messaging and Presence Protocol 770 (XMPP): Instant Messaging", draft-ietf-stox-im-08 (work in 771 progress), March 2014. 773 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 774 / Presence Protocol Requirements", RFC 2779, February 775 2000. 777 Appendix A. Acknowledgements 779 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an 780 early version of this document. 782 Thanks to Mary Barnes, Dave Crocker, Adrian Georgescu, Philipp 783 Hancke, Saul Ibarra Corretge, and Tory Patnoe for their feedback. 785 The authors gratefully acknowledge the assistance of Markus Isomaki 786 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 787 and Alissa Cooper as the sponsoring Area Directors. 789 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 790 employing him during his work on earlier versions of this document. 792 Authors' Addresses 794 Peter Saint-Andre 795 &yet 796 P.O. Box 787 797 Parker, CO 80134 798 USA 800 Email: ietf@stpeter.im 802 Salvatore Loreto 803 Ericsson 804 Hirsalantie 11 805 Jorvas 02420 806 Finland 808 Email: Salvatore.Loreto@ericsson.com