idnits 2.17.1 draft-ietf-stox-chat-05.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 (January 23, 2014) is 3746 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 (-11) exists of draft-ietf-stox-core-09 -- 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-06 Summary: 0 errors (**), 0 flaws (~~), 3 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 4 Intended status: Standards Track S. Loreto 5 Expires: July 27, 2014 Ericsson 6 January 23, 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-05 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 July 27, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Composing Events . . . . . . . . . . . . . . . . . . . . . . 11 61 6. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . 13 62 7. Internationalization Considerations . . . . . . . . . . . . . 14 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 Both the Session Initiation Protocol (SIP) [RFC3261] and the 72 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 73 used for the purpose of one-to-one text chat over the Internet. To 74 ensure interworking between these technologies, it is important to 75 define bidirectional protocol mappings. 77 The architectural assumptions underlying such protocol mappings are 78 provided in [I-D.ietf-stox-core], including mapping of addresses and 79 error conditions. This document specifies mappings for one-to-one 80 text chat sessions (sometimes called "session-mode" messaging); in 81 particular, this document specifies mappings between XMPP messages of 82 type "chat" and the Message Session Relay Protocol (MSRP) [RFC4975], 83 which is commonly used in SIP-based systems for chat functionality 84 (although note that MSRP is not conjoined to SIP, and can be used by 85 non-SIP technologies). Mappings for single instant messages and 86 groupchat are provided in separate documents. 88 The approach taken here is to directly map syntax and semantics from 89 one protocol to another. The mapping described herein depends on the 90 protocols defined in the following specifications: 92 o XMPP chat sessions using message stanzas of type "chat" are 93 specified in [RFC6121]. 95 o MSRP chat sessions using the SIP INVITE and SEND request types are 96 specified in [RFC4975]. 98 In SIP-based systems that use MSRP, a chat session is formally 99 negotiated just as any other session type is using SIP. By contrast, 100 a one-to-one chat "session" in XMPP is an informal construct and is 101 not formally negotiated: a user simply sends a message of type "chat" 102 to a contact, the contact then replies to the message, and the sum 103 total of such messages exchanged during a defined period of time is 104 considered to be a chat session (ideally tied together using an XMPP 105 element as described in Section 5.1 of [RFC6121]). To 106 overcome the disparity between these approaches, a gateway that 107 wishes to map between SIP/MSRP and XMPP for one-to-one chat sessions 108 needs to maintain some additional state, as described below. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [RFC2119]. 117 3. XMPP to MSRP 119 In XMPP, the "informal session" approach is to simply send someone a 120 of type "chat" without starting any session negotiation 121 ahead of time (as described in [RFC6121]). The XMPP "informal 122 session" approach maps very well into a SIP MESSAGE request, as 123 described in [I-D.ietf-stox-core]. However, the XMPP informal 124 session approach can also be mapped to MSRP if the XMPP-to-SIP 125 gateway maintains additional state. 127 The order of events is as follows. 129 XMPP User GW SIP User 130 | | | 131 |(F1) (XMPP) Chat message | | 132 |------------------------->| | 133 | |(F2) (SIP) INVITE | 134 | |------------------------->| 135 | |(F3) (SIP) 200 OK | 136 | |<-------------------------| 137 | |(F4) (SIP) ACK | 138 | |------------------------->| 139 | |(F5) (MSRP) SEND | 140 | |------------------------->| 141 | |(F6) (MSRP) A reply | 142 | |<-------------------------| 143 |(F7) (XMPP) A reply | | 144 |<-------------------------| | 145 | | | 146 . . . 147 . . . 148 . . . 149 | | | 150 | |(F8) (SIP) BYE | 151 | |<-------------------------| 152 | |(F9) (SIP) 200 OK | 153 | |------------------------->| 154 | | | 156 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the 157 following table. (Mappings for several aspects not mentioned here 158 are specified in [I-D.ietf-stox-im].) 160 Table 1: Message syntax mapping from XMPP to SIP 162 +-----------------------------+--------------------------+ 163 | XMPP Element or Attribute | SIP Header or Contents | 164 +-----------------------------+--------------------------+ 165 | | Call-ID | 166 | id | transaction identifier | 167 +-----------------------------+--------------------------+ 169 First the XMPP user would generate an XMPP chat message. 171 Example 1: Juliet sends XMPP message (F1) 173 | 177 | 29377446-0CBB-4296-8958-590D79094C50 178 | Art thou not Romeo, and a Montague? 179 | 181 Upon receiving such a message stanza, the XMPP server needs to 182 determine the identity of the domainpart in the 'to' address, which 183 it does by following the procedures explained in Section 5 of 184 [I-D.ietf-stox-core]. Here we assume that the XMPP server has 185 determined the domain is serviced by an MSRP server, that it contains 186 or has available to it an XMPP-to-SIP gateway or connection manager 187 (which enables it to speak natively to MSRP servers), and that it 188 hands off the message stanza to the XMPP-SIP gateway. 190 The XMPP-to-SIP gateway at the XMPP server would then initiate an 191 MSRP session with Romeo on Juliet's behalf (since there is no 192 reliable way for the gateway to determine if Romeo's client supports 193 MSRP, it simply needs to guess). 195 Example 2: Gateway starts SIP session on behalf of Juliet (F2) 197 | INVITE sip:romeo@example.net SIP/2.0 198 | To: 199 | From: 200 | Contact: ;gr=balcony 201 | Subject: Open chat with Juliet? 202 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 203 | Content-Type: application/sdp 204 | 205 | c=IN IP4 x2s.example.com 206 | m=message 7654 TCP/MSRP * 207 | a=accept-types:text/plain 208 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 210 Here we assume that Romeo accepts the MSRP session request. 212 Example 3: Romeo accepts session request (F3) 214 | SIP/2.0 200 OK 215 | To: 216 | From: 217 | Contact: ;gr=orchard 218 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 219 | Content-Type: application/sdp 220 | 221 | c=IN IP4 s2x.example.net 222 | m=message 12763 TCP/MSRP * 223 | a=accept-types:text/plain 224 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 226 The XMPP-to-SIP gateway then acknowledges the session acceptance on 227 behalf of Juliet. 229 Example 4: Gateway sends ACK to Romeo (F4) 231 | ACK sip:juliet@example.com SIP/2.0 232 | To: ;gr=orchard 233 | From: 234 | Contact: ;gr=balcony 235 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 237 The XMPP-to-SIP gateway then transforms the original XMPP chat 238 message into MSRP. 240 Example 5: Gateway maps XMPP message to MSRP (F5) 242 | MSRP a786hjs2 SEND 243 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 244 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 245 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A 246 | Byte-Range: 1-25/25 247 | Content-Type: text/plain 248 | 249 | Art thou not Romeo, and a Montague? 250 | -------a786hjs2$ 252 Romeo can then send a reply using his MSRP client. 254 Example 6: Romeo sends reply (F6) 256 | MSRP di2fs53v SEND 257 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 258 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 259 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA 260 | Byte-Range: 1-25/25 261 | Failure-Report: no 262 | Content-Type: text/plain 263 | 264 | Neither, fair saint, if either thee dislike. 265 | -------di2fs53v$ 267 The SIP-to-XMPP gateway would then transform that message into 268 appropriate XMPP syntax for routing to the intended recipient. 270 Example 7: Gateway maps MSRP message to XMPP (F7) 271 | 275 | 29377446-0CBB-4296-8958-590D79094C50 276 | Neither, fair saint, if either thee dislike. 277 | 279 When the MSRP user wishes to end the chat session, the user's MSRP 280 client sends a SIP BYE. 282 Example 8: Romeo terminates chat session (F8) 284 | BYE juliet@example.com sip: SIP/2.0 285 | From: ;tag=087js 286 | To: ;tag=786 287 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 288 | Cseq: 1 BYE 289 | Content-Length: 0 291 The BYE is then acknowledged by the XMPP-to-SIP gateway. 293 Example 9: Gateway acknowledges termination (F9) 295 | SIP/2.0 200 OK 296 | From: ;tag=786 297 | To: ;tag=087js 298 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 299 | CSeq: 1 BYE 300 | Content-Length: 0 302 4. MSRP to XMPP 304 When an MSRP client sends messages through a gateway to an XMPP 305 client, the order of events is as follows. 307 SIP User GW XMPP User 308 | | | 309 |(F1)(SIP) INVITE | | 310 |------------------------>| | 311 |(F2)(SIP) 200 OK | | 312 |<------------------------| | 313 |(F3)(SIP) ACK | | 314 |------------------------>| | 315 |(F4)(MSRP) SEND | | 316 |------------------------>| | 317 | |(F5)(XMPP) A chat message | 318 | |------------------------->| 319 | |(F6)(XMPP) A reply | 320 | |<-------------------------| 321 | | | 322 |(F7)(MSRP) SEND | | 323 |<------------------------| | 324 | | | 325 . . . 326 . . . 327 . . . 328 | | | 329 |(F8)(SIP) BYE | | 330 |------------------------>| | 331 |(F9)(SIP) 200 OK | | 332 |<------------------------| | 333 | | | 335 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the 336 following table. (Mappings for several aspects not mentioned here 337 are specified in [I-D.ietf-stox-im].) 339 Table 2: Message syntax mapping from SIP to XMPP 341 +--------------------------+-----------------------------+ 342 | SIP Header or Contents | XMPP Element or Attribute | 343 +--------------------------+-----------------------------+ 344 | Call-ID | | 345 | transaction identifier | id | 346 +--------------------------+-----------------------------+ 348 The protocol flow begins when Romeo starts a chat session with 349 Juliet. 351 Example 10: Romeo starts chat session (F1) 352 | INVITE sip:juliet@example.com SIP/2.0 353 | To: 354 | From: 355 | Contact: ;gr=orchard 356 | Subject: Open chat with Romeo? 357 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 358 | Content-Type: application/sdp 359 | 360 | c=IN IP4 s2x.example.net 361 | m=message 7313 TCP/MSRP * 362 | a=accept-types:text/plain 363 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 365 Upon receiving the INVITE, the SIP (MSRP) server needs to determine 366 the identity of the domain portion of the Request-URI or To header, 367 which it does by following the procedures explained in Section 5 of 368 [I-D.ietf-stox-core]. Here we assume that the SIP server has 369 determined that the domain is serviced by an XMPP server, that it 370 contains or has available to it a SIP-to-XMPP gateway or connection 371 manager (which enables it to speak natively to XMPP servers), and 372 that it hands off the message to the gateway. 374 Example 11: Gateway accepts session on Juliet's behalf (F2) 376 | SIP/2.0 200 OK 377 | To: ;gr=orchard 378 | From: 379 | Contact: ;gr=balcony 380 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 381 | Content-Type: application/sdp 382 | 383 | c=IN IP4 x2s.example.com 384 | m=message 8763 TCP/MSRP * 385 | a=accept-types:text/plain 386 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 388 Example 12: Romeo sends ACK (F3) 390 | ACK sip:juliet@example.com SIP/2.0 391 | To: ;gr=balcony 392 | From: 393 | Contact: ;gr=orchard 394 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 395 Example 13: Romeo sends message (F4) 397 | MSRP ad49kswow SEND 398 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 399 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 400 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E 401 | Byte-Range: 1-32/32 402 | Failure-Report: no 403 | Content-Type: text/plain 404 | 405 | I take thee at thy word ... 406 | -------ad49kswow$ 408 Example 14: SIP-XMPP gateway maps MSRP message to XMPP (F5) 410 | 414 | F6989A8C-DE8A-4E21-8E07-F0898304796F 415 | I take thee at thy word ... 416 | 418 Example 15: Juliet sends reply (F6) 420 | 424 | 29377446-0CBB-4296-8958-590D79094C50 425 | What man art thou ...? 426 | 427 Example 16: Gateway maps XMPP message to MSRP (F7) 429 | MSRP ms53b7z9 SEND 430 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 431 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 432 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 433 | Byte-Range: 1-25/25 434 | Failure-Report: no 435 | Content-Type: text/plain 436 | 437 | What man art thou ...? 438 | -------ms53b7z9$ 440 Example 17: Romeo terminates chat session (F8) 442 | BYE juliet@example.com sip: SIP/2.0 443 | To: ;gr=balcony 444 | From: 445 | Contact: ;gr=orchard 446 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 447 | Cseq: 1 BYE 448 | Content-Length: 0 450 Example 18: Gateway acknowledges termination of session on behalf of 451 Juliet (F9) 453 | SIP/2.0 200 OK 454 | To: ;gr=balcony 455 | From: 456 | Contact: ;gr=orchard 457 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F 458 | CSeq: 1 BYE 460 5. Composing Events 462 Both XMPP and MSRP enable a client to receive notifications when a 463 person's conversation partner is composing an instant message within 464 the context of a chat session. 466 For XMPP, the Chat State Notifications specification [XEP-0085] 467 defines five states: active, inactive, gone, composing, and paused. 468 Some of these states are related to the act of message composition 469 (composing, paused), whereas others are related to the sender's 470 involvement with the chat session (active, inactive, gone). 472 For MSRP (and SIP/SIMPLE in general), the Indication of Message 473 Composition for Instant Messaging specification [RFC3994] defines two 474 states: idle and active. Here the idle state indicates that the 475 sender is not actively composing a message, and the active state 476 indicates that the sender is indeed actively composing a message (the 477 sending client simply toggles between the two states, changing to 478 active if the user is actively composing a message and changing to 479 idle if the user is no longer actively composing a message). 481 Because the XEP-0085 states can represent information that is not 482 captured in RFC 3994, gateways can either (a) map only the composing- 483 related states or (b) map all the XEP-0085 states. 485 The following mappings are suggested. 487 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states 489 +-------------------+--------------------+ 490 | isComposing Event | Chat State | 491 +-------------------+--------------------+ 492 | active | composing | 493 | idle | active | 494 +-------------------+--------------------+ 496 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events 498 +-------------------+--------------------+ 499 | Chat State | isComposing Event | 500 +-------------------+--------------------+ 501 | active | idle | 502 | inactive | idle | 503 | gone | [none, see note] | 504 | composing | active | 505 | paused | idle | 506 +-------------------+--------------------+ 508 Although there is no direct mapping for the "gone" chat state (which 509 is not to be confused with the stanza error condition defined 510 in [RFC6120]) to an isComposing event, receipt of the "gone" state 511 can be used as a trigger for terminating the formal chat session 512 within MSRP, i.e., for sending a SIP BYE for the session from the 513 XMPP-SIP gateway to the SIP user. The following examples illustrate 514 this indirect mapping. 516 Example 19: Juliet sends gone chat state 517 | 521 | 29377446-0CBB-4296-8958-590D79094C50 522 | 523 | 525 Example 20: XMPP-SIP gateway maps gone chat state to SIP BYE 527 | BYE romeo@example.net sip: SIP/2.0 528 | From: ;tag=786 529 | To: ;tag=087js 530 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 531 | Cseq: 1 BYE 532 | Content-Length: 0 534 6. Delivery Reports 536 Both XMPP and MSRP enable a client to receive notifications when a 537 message has been received by the intended recipient. 539 For XMPP, the Message Receipts specification [XEP-0184] defines a 540 method and XML namespace for requesting and returning indications 541 that a message has been received by a client controlled by the 542 intended recipient. 544 For MSRP, a native reporting feature is included, in the form of 545 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). 547 Examples follow. 549 First, the XMPP user sends a message containing a request for 550 delivery notification. 552 Example 21: Juliet sends XMPP message with receipt request 554 | 558 | 29377446-0CBB-4296-8958-590D79094C50 559 | What man art thou ...? 560 | 561 | 562 Example 22: Gateway maps XMPP message to MSRP 564 | MSRP bf9m36d5 SEND 565 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 566 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 567 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 568 | Byte-Range: 1-25/25 569 | Success-Report: yes 570 | Failure-Report: no 571 | Content-Type: text/plain 572 | 573 | What man art thou ...? 574 | -------bf9m36d5$ 576 Next, the recipient returns a report. 578 Example 23: Romeo returns MSRP receipt 580 | MSRP hx74g336 REPORT 581 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 582 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 583 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF 584 | Byte-Range: 1-106/106 585 | Status: 000 200 OK 586 | -------hx74g336$ 588 Example 24: SIP-XMPP gateway maps receipt to XMPP 590 | 593 | 594 | 596 7. Internationalization Considerations 598 Relevant discussion of internationalized text in messages can be 599 found in [I-D.ietf-stox-im]. 601 8. IANA Considerations 603 This document requests no actions of IANA. 605 9. Security Considerations 607 Detailed security considerations for instant messaging protocols are 608 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261] 609 when SIP is used to negotiate MSRP sessions), and for XMPP-based 610 instant messaging in [RFC6121] (see also [RFC6120]). The security 611 considerations provided in [I-D.ietf-stox-core] also apply. 613 This document specifies methods for exchanging instant messages 614 through a gateway that translates between SIP/MSRP and XMPP. Such a 615 gateway MUST be compliant with the minimum security requirements of 616 the textual chat protocols for which it translates (i.e., MSRP and 617 XMPP). The addition of gateways to the security model of instant 618 messaging specified in [RFC2779] introduces some new risks. In 619 particular, end-to-end security properties (especially 620 confidentiality and integrity) between instant messaging clients that 621 interface through an MSRP-XMPP gateway can be provided only if common 622 formats are supported. Specification of those common formats is out 623 of scope for this document, although it is suggested to use [RFC3862] 624 for instant messages. 626 10. References 628 10.1. Normative References 630 [I-D.ietf-stox-core] 631 Saint-Andre, P., Houri, A., and J. Hildebrand, 632 "Interworking between the Session Initiation Protocol 633 (SIP) and the Extensible Messaging and Presence Protocol 634 (XMPP): Core", draft-ietf-stox-core-09 (work in progress), 635 December 2013. 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 641 A., Peterson, J., Sparks, R., Handley, M., and E. 642 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 643 June 2002. 645 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 646 Messaging (CPIM): Message Format", RFC 3862, August 2004. 648 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 649 Instant Messaging", RFC 3994, January 2005. 651 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 652 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 654 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 655 Protocol (XMPP): Core", RFC 6120, March 2011. 657 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 658 Protocol (XMPP): Instant Messaging and Presence", RFC 659 6121, March 2011. 661 [XEP-0085] 662 Saint-Andre, P. and D. Smith, "Chat State Notifications", 663 XSF XEP 0085, September 2009. 665 [XEP-0184] 666 Saint-Andre, P. and J. Hildebrand, "Message Delivery 667 Receipts", XSF XEP 0184, March 2011. 669 10.2. Informative References 671 [I-D.ietf-stox-im] 672 Saint-Andre, P., Houri, A., and J. Hildebrand, 673 "Interworking between the Session Initiation Protocol 674 (SIP) and the Extensible Messaging and Presence Protocol 675 (XMPP): Instant Messaging", draft-ietf-stox-im-06 (work in 676 progress), December 2013. 678 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 679 / Presence Protocol Requirements", RFC 2779, February 680 2000. 682 Appendix A. Acknowledgements 684 Special thanks to Eddy Gavita and Nazin Hossain for their co- 685 authorship of an early version of this document. 687 Thanks to Mary Barnes, Adrian Georgescu, Philipp Hancke, Saul Ibarra 688 Corretge, and Tory Patnoe for their feedback. 690 The authors gratefully acknowledge the assistance of Markus Isomaki 691 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 692 as the sponsoring Area Director. 694 Authors' Addresses 695 Peter Saint-Andre 697 Email: ietf@stpeter.im 699 Salvatore Loreto 700 Ericsson 701 Hirsalantie 11 702 Jorvas 02420 703 Finland 705 Email: Salvatore.Loreto@ericsson.com