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