idnits 2.17.1
draft-ietf-stox-chat-07.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 (June 9, 2014) is 3608 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: December 11, 2014 Ericsson
6 June 9, 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-07
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 December 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17
67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
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 [RFC7247], including mapping of addresses and error
80 conditions. This document specifies mappings for one-to-one text
81 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 [RFC7247], and with the following chat-
120 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 [RFC7247]. However, the XMPP informal session approach
151 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains
152 additional state. The order of events is as follows.
154 XMPP XMPP XMPP-to-MSRP SIP SIP
155 User Server Gateway Server User
156 | | | | |
157 | (F1) XMPP | | | |
158 | message | | | |
159 |..............>| | | |
160 | | (F2) XMPP | | |
161 | | message | | |
162 | |..............>| | |
163 | | | (F3) SIP | |
164 | | | INVITE | |
165 | | |**************>| |
166 | | | | (F4) SIP |
167 | | | | INVITE |
168 | | | |**************>|
169 | | | | (F5) SIP |
170 | | | | 200 OK |
171 | | | |<**************|
172 | | | (F6) SIP | |
173 | | | 200 OK | |
174 | | |<**************| |
175 | | | (F7) SIP ACK | |
176 | | |**************>| |
177 | | | | (F8) SIP ACK |
178 | | | |**************>|
179 | | | (F9) MSRP SEND |
180 | | |******************************>|
181 . . . . .
182 . . . . .
183 | | | (F10) MSRP SEND |
184 | | |<******************************|
185 | | (F11) XMPP | | |
186 | | message | | |
187 | |<..............| | |
188 | (F12) XMPP | | | |
189 | message | | | |
190 |<..............| | | |
191 . . . . .
193 . . . . .
194 | | | | (F13) SIP BYE |
195 | | | |<**************|
196 | | | (F14) SIP BYE | |
197 | | |<**************| |
198 | | | (F15) SIP | |
199 | | | 200 OK | |
200 | | |**************>| |
201 | | | | (F16) SIP |
202 | | | | 200 OK |
203 | | | |**************>|
205 Figure 1: XMPP to MSRP Order of Events
207 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the
208 following table. (Mappings for several aspects not mentioned here
209 are specified in [I-D.ietf-stox-im].)
211 Table 1: Message syntax mapping from XMPP to SIP
213 +-----------------------------+--------------------------+
214 | XMPP Element or Attribute | SIP Header or Contents |
215 +-----------------------------+--------------------------+
216 | | Call-ID |
217 | id | transaction identifier |
218 +-----------------------------+--------------------------+
220 First the XMPP user would generate an XMPP chat message.
222 Example 1: Juliet sends XMPP message (F1)
224 |
228 | 29377446-0CBB-4296-8958-590D79094C50
229 | Art thou not Romeo, and a Montague?
230 |
232 Upon receiving such a message stanza, the XMPP server needs to
233 determine the identity of the domainpart in the 'to' address, which
234 it does by following the procedures explained in Section 5 of
235 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand
236 off the message stanza to an XMPP-to-SIP gateway or connection
237 manager that natively communicates with MSRP-aware SIP servers.
239 The XMPP-to-SIP gateway at the XMPP server would then initiate an
240 MSRP session with Romeo on Juliet's behalf (since there is no
241 reliable way for the gateway to determine if Romeo's client supports
242 MSRP, it simply needs to guess).
244 Example 2: Gateway starts SIP session on behalf of Juliet (F3)
246 | INVITE sip:romeo@example.net SIP/2.0
247 | To:
248 | From:
249 | Contact: ;gr=balcony
250 | Subject: Open chat with Juliet?
251 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
252 | Content-Type: application/sdp
253 |
254 | c=IN IP4 x2s.example.com
255 | m=message 7654 TCP/MSRP *
256 | a=accept-types:text/plain
257 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
259 Here we assume that Romeo accepts the MSRP session request.
261 Example 3: Romeo accepts session request (F5)
263 | SIP/2.0 200 OK
264 | To:
265 | From:
266 | Contact: ;gr=orchard
267 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
268 | Content-Type: application/sdp
269 |
270 | c=IN IP4 s2x.example.net
271 | m=message 12763 TCP/MSRP *
272 | a=accept-types:text/plain
273 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
275 The XMPP-to-SIP gateway then acknowledges the session acceptance on
276 behalf of Juliet.
278 Example 4: Gateway sends ACK to Romeo (F7)
280 | ACK sip:juliet@example.com SIP/2.0
281 | To: ;gr=orchard
282 | From:
283 | Contact: ;gr=balcony
284 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
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=087js
336 | To: ;tag=786
337 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
338 | Cseq: 1 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: 1 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 5. MSRP to XMPP
359 When an MSRP client sends messages through a gateway to an XMPP
360 client, the order of events is as follows.
362 SIP SIP MSRP-to-XMPP XMPP XMPP
363 User Server Gateway Server User
364 | | | | |
365 | (F17) SIP | | | |
366 | INVITE | | | |
367 |**************>| | | |
368 | | (F18) SIP | | |
369 | | INVITE | | |
370 | |**************>| | |
371 | | (F19) SIP | | |
372 | | 200 OK | | |
373 | |<**************| | |
374 | (F20) SIP | | | |
375 | 200 OK | | | |
376 |<**************| | | |
377 | (F21) SIP ACK | | | |
378 |**************>| | | |
379 | | (F22) SIP ACK | | |
380 | |**************>| | |
381 | (F23) MSRP SEND | | |
382 |******************************>| | |
383 | | | (F24) XMPP | |
384 | | | message | |
385 | | |..............>| |
386 | | | | (F25) XMPP |
387 | | | | message |
388 | | | |..............>|
389 . . . . .
390 . . . . .
391 | | | | (F26) XMPP |
392 | | | | message |
393 | | | |<..............|
394 | | | (F27) XMPP | |
395 | | | message | |
396 | | |<..............| |
397 | (F28) MSRP SEND | | |
398 |<******************************| | |
399 . . . . .
400 . . . . .
401 | | | | |
402 | | | | |
403 | (F29) SIP BYE | | | |
404 |**************>| | | |
405 | | (F30) SIP BYE | | |
406 | |**************>| | |
407 | | (F31) SIP | | |
408 | | 200 OK | | |
409 | |<**************| | |
410 | (F36) SIP | | | |
411 | 200 OK | | | |
412 |<**************| | | |
414 Figure 2: MSRP to XMPP Order of Events
416 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the
417 following table. (Mappings for several aspects not mentioned here
418 are specified in [I-D.ietf-stox-im].)
420 Table 2: Message syntax mapping from SIP to XMPP
422 +--------------------------+-----------------------------+
423 | SIP Header or Contents | XMPP Element or Attribute |
424 +--------------------------+-----------------------------+
425 | Call-ID | |
426 | transaction identifier | id |
427 +--------------------------+-----------------------------+
429 The protocol flow begins when Romeo starts a chat session with
430 Juliet.
432 Example 10: Romeo starts chat session (F17)
434 | INVITE sip:juliet@example.com SIP/2.0
435 | To:
436 | From:
437 | Contact: ;gr=orchard
438 | Subject: Open chat with Romeo?
439 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
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 | To: ;gr=orchard
458 | From:
459 | Contact: ;gr=balcony
460 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
461 | Content-Type: application/sdp
462 |
463 | c=IN IP4 x2s.example.com
464 | m=message 8763 TCP/MSRP *
465 | a=accept-types:text/plain
466 | 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=balcony
472 | From:
473 | Contact: ;gr=orchard
474 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
475 Example 13: Romeo sends message (F23)
477 | MSRP ad49kswow SEND
478 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
479 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
480 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
481 | Byte-Range: 1-32/32
482 | Failure-Report: no
483 | Content-Type: text/plain
484 |
485 | I take thee at thy word ...
486 | -------ad49kswow$
488 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24)
490 |
494 | F6989A8C-DE8A-4E21-8E07-F0898304796F
495 | I take thee at thy word ...
496 |
498 Example 15: Juliet sends reply (F26)
500 |
504 | 29377446-0CBB-4296-8958-590D79094C50
505 | What man art thou ...?
506 |
508 Example 16: Gateway maps XMPP message to MSRP (F28)
510 | MSRP ms53b7z9 SEND
511 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
512 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
513 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
514 | Byte-Range: 1-25/25
515 | Failure-Report: no
516 | Content-Type: text/plain
517 |
518 | What man art thou ...?
519 | -------ms53b7z9$
520 Example 17: Romeo terminates chat session (F29)
522 | BYE juliet@example.com sip: SIP/2.0
523 | To: ;gr=balcony
524 | From:
525 | Contact: ;gr=orchard
526 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
527 | Cseq: 1 BYE
528 | Content-Length: 0
530 Example 18: Gateway acknowledges termination of session on behalf of
531 Juliet (F31)
533 | SIP/2.0 200 OK
534 | To: ;gr=balcony
535 | From:
536 | Contact: ;gr=orchard
537 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
538 | CSeq: 1 BYE
540 6. Composing Events
542 Both XMPP and MSRP enable a client to receive notifications when a
543 person's conversation partner is composing an instant message within
544 the context of a chat session.
546 For XMPP, the Chat State Notifications specification [XEP-0085]
547 defines five states: active, inactive, gone, composing, and paused.
548 Some of these states are related to the act of message composition
549 (composing, paused), whereas others are related to the sender's
550 involvement with the chat session (active, inactive, gone). Note
551 that the "gone" chat state is not to be confused with the
552 stanza error condition defined in [RFC6120].
554 For MSRP (and SIP/SIMPLE in general), the Indication of Message
555 Composition for Instant Messaging specification [RFC3994] defines two
556 states: idle and active. Here the idle state indicates that the
557 sender is not actively composing a message, and the active state
558 indicates that the sender is indeed actively composing a message (the
559 sending client simply toggles between the two states, changing to
560 active if the user is actively composing a message and changing to
561 idle if the user is no longer actively composing a message).
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 note] |
586 | composing | active |
587 | paused | idle |
588 +-------------------+--------------------+
590 6.1. Use of the Gone Chat State
592 Although there is no direct mapping for the "gone" chat state to an
593 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP
594 gateway can serve as a trigger for terminating the formal chat
595 session within MSRP, i.e., for sending a SIP BYE for the session from
596 the XMPP-to-MSRP gateway to the SIP user. The following examples
597 illustrate this indirect mapping (which would occur after step F14 in
598 Figure 1).
600 Example 19: Juliet sends gone chat state
602 |
606 | 29377446-0CBB-4296-8958-590D79094C50
607 |
608 |
609 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE
611 | BYE romeo@example.net sip: SIP/2.0
612 | From: ;tag=786
613 | To: ;tag=087js
614 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
615 | Cseq: 1 BYE
616 | Content-Length: 0
618 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway
619 can server as a trigger for sending a "gone" chat state notification
620 to the XMPP user. The following examples illustrate this indirect
621 mapping (which would occur after step F30 in Figure 2).
623 Example 21: Romeo terminates chat session
625 | BYE juliet@example.com sip: SIP/2.0
626 | To: ;gr=balcony
627 | From:
628 | Contact: ;gr=orchard
629 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
630 | Cseq: 1 BYE
631 | Content-Length: 0
633 Example 22: MSRP-to-XMPP gateway generates gone chat state
635 |
639 | F6989A8C-DE8A-4E21-8E07-F0898304796F
640 |
641 |
643 To enable these uses, gateways that support chat state notifications
644 MUST support the "gone" state (which is merely recommended, not
645 required, by [XEP-0085]).
647 It is also reasonable for gateways to implement timers that
648 automatically trigger a "gone" chat state if the XMPP user has not
649 sent a message within the "session" for a given amount of time.
651 7. Delivery Reports
653 Both XMPP and MSRP enable a client to receive notifications when a
654 message has been received by the intended recipient.
656 For XMPP, the Message Receipts specification [XEP-0184] defines a
657 method and XML namespace for requesting and returning indications
658 that a message has been received by a client controlled by the
659 intended recipient.
661 For MSRP, a native reporting feature is included, in the form of
662 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
664 Examples follow.
666 First, the XMPP user sends a message containing a request for
667 delivery notification.
669 Example 23: Juliet sends XMPP message with receipt request
671 |
675 | 29377446-0CBB-4296-8958-590D79094C50
676 | What man art thou ...?
677 |
678 |
680 Example 24: Gateway maps XMPP message to MSRP
682 | MSRP bf9m36d5 SEND
683 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
684 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
685 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
686 | Byte-Range: 1-25/25
687 | Success-Report: yes
688 | Failure-Report: no
689 | Content-Type: text/plain
690 |
691 | What man art thou ...?
692 | -------bf9m36d5$
694 Next, the recipient returns a report.
696 Example 25: Romeo returns MSRP receipt
698 | MSRP hx74g336 REPORT
699 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
700 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
701 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
702 | Byte-Range: 1-106/106
703 | Status: 000 200 OK
704 | -------hx74g336$
706 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP
708 |
711 |
712 |
714 8. Internationalization Considerations
716 Relevant discussion of internationalized text in messages can be
717 found in [I-D.ietf-stox-im].
719 9. IANA Considerations
721 This document requests no actions of IANA.
723 10. Security Considerations
725 Detailed security considerations for instant messaging protocols are
726 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261]
727 when SIP is used to negotiate MSRP sessions), and for XMPP-based
728 instant messaging in [RFC6121] (see also [RFC6120]). The security
729 considerations provided in [RFC7247] also apply.
731 This document specifies methods for exchanging instant messages
732 through a gateway that translates between SIP/MSRP and XMPP. Such a
733 gateway MUST be compliant with the minimum security requirements of
734 the textual chat protocols for which it translates (i.e., MSRP and
735 XMPP). The addition of gateways to the security model of instant
736 messaging specified in [RFC2779] introduces some new risks. In
737 particular, end-to-end security properties (especially
738 confidentiality and integrity) between instant messaging clients that
739 interface through an MSRP-XMPP gateway can be provided only if common
740 formats are supported. Specification of those common formats is out
741 of scope for this document, although it is suggested to use [RFC3862]
742 for instant messages.
744 11. References
746 11.1. Normative References
748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
749 Requirement Levels", BCP 14, RFC 2119, March 1997.
751 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
752 A., Peterson, J., Sparks, R., Handley, M., and E.
753 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
754 June 2002.
756 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
757 Messaging (CPIM): Message Format", RFC 3862, August 2004.
759 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
760 Instant Messaging", RFC 3994, January 2005.
762 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
763 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
765 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
766 Protocol (XMPP): Core", RFC 6120, March 2011.
768 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
769 Protocol (XMPP): Instant Messaging and Presence", RFC
770 6121, March 2011.
772 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
773 "Interworking between the Session Initiation Protocol
774 (SIP) and the Extensible Messaging and Presence Protocol
775 (XMPP): Architecture, Addresses, and Error Handling", RFC
776 7247, May 2014.
778 [XEP-0085]
779 Saint-Andre, P. and D. Smith, "Chat State Notifications",
780 XSF XEP 0085, September 2009.
782 [XEP-0184]
783 Saint-Andre, P. and J. Hildebrand, "Message Delivery
784 Receipts", XSF XEP 0184, March 2011.
786 11.2. Informative References
788 [I-D.ietf-stox-im]
789 Saint-Andre, P., Houri, A., and J. Hildebrand,
790 "Interworking between the Session Initiation Protocol
791 (SIP) and the Extensible Messaging and Presence Protocol
792 (XMPP): Instant Messaging", draft-ietf-stox-im-08 (work in
793 progress), March 2014.
795 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
796 / Presence Protocol Requirements", RFC 2779, February
797 2000.
799 Appendix A. Acknowledgements
801 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an
802 early version of this document.
804 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu,
805 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for
806 their feedback.
808 The authors gratefully acknowledge the assistance of Markus Isomaki
809 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
810 and Alissa Cooper as the sponsoring Area Directors.
812 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
813 employing him during his work on earlier versions of this document.
815 Authors' Addresses
817 Peter Saint-Andre
818 &yet
819 P.O. Box 787
820 Parker, CO 80134
821 USA
823 Email: peter@andyet.com
825 Salvatore Loreto
826 Ericsson
827 Hirsalantie 11
828 Jorvas 02420
829 Finland
831 Email: Salvatore.Loreto@ericsson.com