idnits 2.17.1
draft-ietf-stox-chat-09.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 (February 2, 2015) is 3371 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-10
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: August 6, 2015 Ericsson
6 February 2, 2015
8 Interworking between the Session Initiation Protocol (SIP) and the
9 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat
10 Sessions
11 draft-ietf-stox-chat-09
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 August 6, 2015.
39 Copyright Notice
41 Copyright (c) 2015 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3
58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 4. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . 4
60 5. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . 8
61 6. Composing Events . . . . . . . . . . . . . . . . . . . . . . 12
62 7. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . 15
63 8. Internationalization Considerations . . . . . . . . . . . . . 16
64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
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 Note well that not all protocol-compliant messages are shown (such as
132 SIP 100 TRYING messages), in order to focus the reader on the
133 essential aspects of the protocol flows.
135 3. Terminology
137 A number of terms used here are explained in [RFC3261], [RFC4975],
138 [RFC6120], and [RFC6121].
140 In flow diagrams, SIP/MSRP traffic is shown using arrows such as
141 "***>" whereas XMPP traffic is shown using arrows such as "...>".
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
145 "OPTIONAL" in this document are to be interpreted as described in
146 [RFC2119].
148 4. XMPP to MSRP
150 In XMPP, the "informal session" approach is to simply send someone a
151 of type "chat" without starting any session negotiation
152 ahead of time (as described in [RFC6121]). The XMPP "informal
153 session" approach maps very well into a SIP MESSAGE request, as
154 described in [RFC7247]. However, the XMPP informal session approach
155 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains
156 additional state. The order of events is as follows.
158 XMPP XMPP XMPP-to-MSRP SIP SIP
159 User Server Gateway Server User
160 | | | | |
161 | (F1) XMPP | | | |
162 | message | | | |
163 |..............>| | | |
164 | | (F2) XMPP | | |
165 | | message | | |
166 | |..............>| | |
167 | | | (F3) SIP | |
168 | | | INVITE | |
169 | | |**************>| |
170 | | | | (F4) SIP |
171 | | | | INVITE |
172 | | | |**************>|
173 | | | | (F5) SIP |
174 | | | | 200 OK |
175 | | | |<**************|
176 | | | (F6) SIP | |
177 | | | 200 OK | |
178 | | |<**************| |
179 | | | (F7) SIP ACK | |
180 | | |**************>| |
181 | | | | (F8) SIP ACK |
182 | | | |**************>|
183 | | | (F9) MSRP SEND |
184 | | |******************************>|
185 . . . . .
186 . . . . .
187 | | | (F10) MSRP SEND |
188 | | |<******************************|
189 | | (F11) XMPP | | |
190 | | message | | |
191 | |<..............| | |
192 | (F12) XMPP | | | |
193 | message | | | |
194 |<..............| | | |
195 . . . . .
196 . . . . .
197 | | | | (F13) SIP BYE |
198 | | | |<**************|
199 | | | (F14) SIP BYE | |
200 | | |<**************| |
201 | | | (F15) SIP | |
202 | | | 200 OK | |
203 | | |**************>| |
204 | | | | (F16) SIP |
205 | | | | 200 OK |
206 | | | |**************>|
208 Figure 1: XMPP to MSRP Order of Events
210 The mapping of XMPP syntax to SIP syntax MUST be as shown in the
211 following table. (Mappings for several aspects not mentioned here
212 are specified in [I-D.ietf-stox-im].)
214 Table 1: Message syntax mapping from XMPP to SIP
216 +-----------------------------+--------------------------+
217 | XMPP Element or Attribute | SIP Header or Contents |
218 +-----------------------------+--------------------------+
219 | | Call-ID |
220 | id | transaction identifier |
221 +-----------------------------+--------------------------+
223 First the XMPP user would generate an XMPP chat message.
225 Example 1: Juliet sends XMPP message (F1)
227 |
231 | 29377446-0CBB-4296-8958-590D79094C50
232 | Art thou not Romeo, and a Montague?
233 |
235 Upon receiving such a message stanza, the XMPP server needs to
236 determine the identity of the domainpart in the 'to' address, which
237 it does by following the procedures explained in Section 5 of
238 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand
239 off the message stanza to an XMPP-to-SIP gateway or connection
240 manager that natively communicates with MSRP-aware SIP servers.
242 The XMPP-to-SIP gateway at the XMPP server would then initiate an
243 MSRP session with Romeo on Juliet's behalf (since there is no
244 reliable way for the gateway to determine whether Romeo's client
245 supports MSRP, if that is not the case then MSRP session initiation
246 might result in an error).
248 Example 2: Gateway starts SIP session on behalf of Juliet (F3)
250 | INVITE sip:romeo@example.net SIP/2.0
251 | To:
252 | From:
253 | Contact: ;gr=yn0cl4bnw0yr3vym
254 | Subject: Open chat with Juliet?
255 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
256 | Content-Type: application/sdp
257 |
258 | c=IN IP4 x2s.example.com
259 | m=message 7654 TCP/MSRP *
260 | a=accept-types:text/plain
261 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
263 Here we assume that Romeo's client supports MSRP and that Romeo
264 accepts the MSRP session request.
266 Example 3: Romeo accepts session request (F5)
268 | SIP/2.0 200 OK
269 | To:
270 | From:
271 | Contact: ;gr=dr4hcr0st3lup4c
272 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
273 | Content-Type: application/sdp
274 |
275 | c=IN IP4 s2x.example.net
276 | m=message 12763 TCP/MSRP *
277 | a=accept-types:text/plain
278 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
280 The XMPP-to-SIP gateway then acknowledges the session acceptance on
281 behalf of Juliet.
283 Example 4: Gateway sends ACK to Romeo (F7)
285 | ACK sip:juliet@example.com SIP/2.0
286 | To: ;gr=dr4hcr0st3lup4c
287 | From:
288 | Contact: ;gr=yn0cl4bnw0yr3vym
289 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
291 The XMPP-to-SIP gateway then transforms the original XMPP chat
292 message into MSRP.
294 Example 5: Gateway maps XMPP message to MSRP (F9)
296 | MSRP a786hjs2 SEND
297 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
298 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
299 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A
300 | Byte-Range: 1-25/25
301 | Content-Type: text/plain
302 |
303 | Art thou not Romeo, and a Montague?
304 | -------a786hjs2$
306 Romeo can then send a reply using his MSRP client.
308 Example 6: Romeo sends reply (F10)
310 | MSRP di2fs53v SEND
311 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
312 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
313 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA
314 | Byte-Range: 1-25/25
315 | Failure-Report: no
316 | Content-Type: text/plain
317 |
318 | Neither, fair saint, if either thee dislike.
319 | -------di2fs53v$
321 The SIP-to-XMPP gateway would then transform that message into
322 appropriate XMPP syntax for routing to the intended recipient.
324 Example 7: Gateway maps MSRP message to XMPP (F11)
326 |
330 | 29377446-0CBB-4296-8958-590D79094C50
331 | Neither, fair saint, if either thee dislike.
332 |
334 When the MSRP user wishes to end the chat session, the user's MSRP
335 client sends a SIP BYE.
337 Example 8: Romeo terminates chat session (F13)
339 | BYE juliet@example.com sip: SIP/2.0
340 | From: ;tag=087js
341 | To: ;tag=786
342 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
343 | Cseq: 1 BYE
344 | Content-Length: 0
346 The BYE is then acknowledged by the XMPP-to-SIP gateway.
348 Example 9: Gateway acknowledges termination (F15)
350 | SIP/2.0 200 OK
351 | From: ;tag=786
352 | To: ;tag=087js
353 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
354 | CSeq: 1 BYE
355 | Content-Length: 0
357 Because there is no formal session on the XMPP side, there is no
358 corresponding communication from the gateway to the XMPP user.
359 However, it is reasonable for the gateway to send a "gone" chat state
360 notification [XEP-0085], as described under Section 6.1.
362 5. MSRP to XMPP
364 When an MSRP client sends messages through a gateway to an XMPP
365 client, the order of events is as follows.
367 SIP SIP MSRP-to-XMPP XMPP XMPP
368 User Server Gateway Server User
369 | | | | |
370 | (F17) SIP | | | |
371 | INVITE | | | |
372 |**************>| | | |
373 | | (F18) SIP | | |
374 | | INVITE | | |
375 | |**************>| | |
376 | | (F19) SIP | | |
377 | | 200 OK | | |
378 | |<**************| | |
379 | (F20) SIP | | | |
380 | 200 OK | | | |
381 |<**************| | | |
382 | (F21) SIP ACK | | | |
383 |**************>| | | |
384 | | (F22) SIP ACK | | |
385 | |**************>| | |
386 | (F23) MSRP SEND | | |
387 |******************************>| | |
388 | | | (F24) XMPP | |
389 | | | message | |
390 | | |..............>| |
391 | | | | (F25) XMPP |
392 | | | | message |
393 | | | |..............>|
394 . . . . .
395 . . . . .
396 | | | | (F26) XMPP |
397 | | | | message |
398 | | | |<..............|
399 | | | (F27) XMPP | |
400 | | | message | |
401 | | |<..............| |
402 | (F28) MSRP SEND | | |
403 |<******************************| | |
404 . . . . .
405 . . . . .
406 | | | | |
407 | | | | |
408 | (F29) SIP BYE | | | |
409 |**************>| | | |
410 | | (F30) SIP BYE | | |
411 | |**************>| | |
412 | | (F31) SIP | | |
413 | | 200 OK | | |
414 | |<**************| | |
415 | (F32) SIP | | | |
416 | 200 OK | | | |
417 |<**************| | | |
419 Figure 2: MSRP to XMPP Order of Events
421 The mapping of SIP syntax to XMPP syntax MUST be as shown in the
422 following table. (Mappings for several aspects not mentioned here
423 are specified in [I-D.ietf-stox-im].)
425 Table 2: Message syntax mapping from SIP to XMPP
427 +--------------------------+-----------------------------+
428 | SIP Header or Contents | XMPP Element or Attribute |
429 +--------------------------+-----------------------------+
430 | Call-ID | |
431 | transaction identifier | id |
432 +--------------------------+-----------------------------+
434 The protocol flow begins when Romeo starts a chat session with
435 Juliet.
437 Example 10: Romeo starts chat session (F17)
439 | INVITE sip:juliet@example.com SIP/2.0
440 | To:
441 | From:
442 | Contact: ;gr=dr4hcr0st3lup4c
443 | Subject: Open chat with Romeo?
444 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
445 | Content-Type: application/sdp
446 |
447 | c=IN IP4 s2x.example.net
448 | m=message 7313 TCP/MSRP *
449 | a=accept-types:text/plain
450 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
452 Upon receiving the INVITE, the SIP (MSRP) server needs to determine
453 the identity of the domain portion of the Request-URI or To header,
454 which it does by following the procedures explained in Section 5 of
455 [RFC7247]. If the domain is an XMPP domain, the SIP server will hand
456 off the INVITE to an associated MSRP-to-XMPP gateway or connection
457 manager that natively communicates with XMPP servers.
459 Example 11: Gateway accepts session on Juliet's behalf (F19)
461 | SIP/2.0 200 OK
462 | To: ;gr=dr4hcr0st3lup4c
463 | From:
464 | Contact: ;gr=yn0cl4bnw0yr3vym
465 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
466 | Content-Type: application/sdp
467 |
468 | c=IN IP4 x2s.example.com
469 | m=message 8763 TCP/MSRP *
470 | a=accept-types:text/plain
471 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
473 Example 12: Romeo sends ACK (F21)
475 | ACK sip:juliet@example.com SIP/2.0
476 | To: ;gr=yn0cl4bnw0yr3vym
477 | From:
478 | Contact: ;gr=dr4hcr0st3lup4c
479 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
481 Example 13: Romeo sends message (F23)
483 | MSRP ad49kswow SEND
484 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
485 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
486 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
487 | Byte-Range: 1-32/32
488 | Failure-Report: no
489 | Content-Type: text/plain
490 |
491 | I take thee at thy word ...
492 | -------ad49kswow$
494 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24)
496 |
500 | F6989A8C-DE8A-4E21-8E07-F0898304796F
501 | I take thee at thy word ...
502 |
503 Example 15: Juliet sends reply (F26)
505 |
509 | 29377446-0CBB-4296-8958-590D79094C50
510 | What man art thou ...?
511 |
513 Example 16: Gateway maps XMPP message to MSRP (F28)
515 | MSRP ms53b7z9 SEND
516 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
517 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
518 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
519 | Byte-Range: 1-25/25
520 | Failure-Report: no
521 | Content-Type: text/plain
522 |
523 | What man art thou ...?
524 | -------ms53b7z9$
526 Example 17: Romeo terminates chat session (F29)
528 | BYE juliet@example.com sip: SIP/2.0
529 | To: ;gr=yn0cl4bnw0yr3vym
530 | From:
531 | Contact: ;gr=dr4hcr0st3lup4c
532 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
533 | Cseq: 1 BYE
534 | Content-Length: 0
536 Example 18: Gateway acknowledges termination of session on behalf of
537 Juliet (F31)
539 | SIP/2.0 200 OK
540 | To: ;gr=yn0cl4bnw0yr3vym
541 | From:
542 | Contact: ;gr=dr4hcr0st3lup4c
543 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
544 | CSeq: 1 BYE
546 6. Composing Events
548 Both XMPP and MSRP enable a client to receive notifications when a
549 person's conversation partner is composing an instant message within
550 the context of a chat session.
552 For XMPP, the Chat State Notifications specification [XEP-0085]
553 defines five states: active, inactive, gone, composing, and paused.
554 Some of these states are related to the act of message composition
555 (composing, paused), whereas others are related to the sender's
556 involvement with the chat session (active, inactive, gone). Note
557 that the "gone" chat state is not to be confused with the
558 stanza error condition defined in [RFC6120].
560 For MSRP (and SIP/SIMPLE in general), the Indication of Message
561 Composition for Instant Messaging specification [RFC3994] defines two
562 states: idle and active. Here the idle state indicates that the
563 sender is not actively composing a message, and the active state
564 indicates that the sender is indeed actively composing a message (the
565 sending client simply toggles between the two states, changing to
566 active if the user is actively composing a message and changing to
567 idle if the user is no longer actively composing a message).
569 Because the XEP-0085 states can represent information that is not
570 captured in RFC 3994, gateways can either (a) map only the composing-
571 related states or (b) map all the XEP-0085 states.
573 The following mappings are suggested.
575 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states
577 +-------------------+--------------------+
578 | isComposing Event | Chat State |
579 +-------------------+--------------------+
580 | active | composing |
581 | idle | active |
582 +-------------------+--------------------+
584 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events
586 +-------------------+--------------------+
587 | Chat State | isComposing Event |
588 +-------------------+--------------------+
589 | active | idle |
590 | inactive | idle |
591 | gone | [none, see note] |
592 | composing | active |
593 | paused | idle |
594 +-------------------+--------------------+
596 6.1. Use of the Gone Chat State
598 Although there is no direct mapping for the "gone" chat state to an
599 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP
600 gateway can serve as a trigger for terminating the formal chat
601 session within MSRP, i.e., for sending a SIP BYE for the session from
602 the XMPP-to-MSRP gateway to the SIP user. The following examples
603 illustrate this indirect mapping (which would occur after step F14 in
604 Figure 1).
606 Example 19: Juliet sends gone chat state
608 |
612 | 29377446-0CBB-4296-8958-590D79094C50
613 |
614 |
616 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE
618 | BYE romeo@example.net sip: SIP/2.0
619 | From: ;tag=786
620 | To: ;tag=087js
621 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
622 | Cseq: 1 BYE
623 | Content-Length: 0
625 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway
626 can serve as a trigger for sending a "gone" chat state notification
627 to the XMPP user. The following examples illustrate this indirect
628 mapping (which would occur after step F30 in Figure 2).
630 Example 21: Romeo terminates chat session
632 | BYE juliet@example.com sip: SIP/2.0
633 | To: ;gr=yn0cl4bnw0yr3vym
634 | From:
635 | Contact: ;gr=dr4hcr0st3lup4c
636 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
637 | Cseq: 1 BYE
638 | Content-Length: 0
639 Example 22: MSRP-to-XMPP gateway generates gone chat state
641 |
645 | F6989A8C-DE8A-4E21-8E07-F0898304796F
646 |
647 |
649 To enable these uses, gateways that support chat state notifications
650 MUST support the "gone" state (which is merely recommended, not
651 required, by [XEP-0085]).
653 It is also reasonable for gateways to implement timers that
654 automatically trigger a "gone" chat state if the XMPP user has not
655 sent a message within the "session" for a given amount of time.
657 7. Delivery Reports
659 Both XMPP and MSRP enable a client to receive notifications when a
660 message has been received by the intended recipient.
662 For XMPP, the Message Receipts specification [XEP-0184] defines a
663 method and XML namespace for requesting and returning indications
664 that a message has been received by a client controlled by the
665 intended recipient.
667 For MSRP, a native reporting feature is included, in the form of
668 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
670 Examples follow.
672 First, the XMPP user sends a message containing a request for
673 delivery notification.
675 Example 23: Juliet sends XMPP message with receipt request
677 |
681 | 29377446-0CBB-4296-8958-590D79094C50
682 | What man art thou ...?
683 |
684 |
685 Example 24: Gateway maps XMPP message to MSRP
687 | MSRP bf9m36d5 SEND
688 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
689 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
690 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
691 | Byte-Range: 1-25/25
692 | Success-Report: yes
693 | Failure-Report: no
694 | Content-Type: text/plain
695 |
696 | What man art thou ...?
697 | -------bf9m36d5$
699 Next, the recipient returns a report.
701 Example 25: Romeo returns MSRP receipt
703 | MSRP hx74g336 REPORT
704 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
705 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
706 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
707 | Byte-Range: 1-106/106
708 | Status: 000 200 OK
709 | -------hx74g336$
711 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP
713 |
716 |
717 |
719 8. Internationalization Considerations
721 Relevant discussion of internationalized text in messages can be
722 found in [I-D.ietf-stox-im].
724 9. IANA Considerations
726 This document requests no actions of IANA.
728 10. Security Considerations
730 Detailed security considerations for instant messaging protocols are
731 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261]
732 when SIP is used to negotiate MSRP sessions), and for XMPP-based
733 instant messaging in [RFC6121] (see also [RFC6120]). The security
734 considerations provided in [RFC7247] also apply.
736 This document specifies methods for exchanging instant messages
737 through a gateway that translates between SIP/MSRP and XMPP. Such a
738 gateway MUST be compliant with the minimum security requirements of
739 the textual chat protocols for which it translates (i.e., MSRP and
740 XMPP). The addition of gateways to the security model of instant
741 messaging specified in [RFC2779] introduces some new risks. In
742 particular, end-to-end security properties (especially
743 confidentiality and integrity) between instant messaging clients that
744 interface through an MSRP-XMPP gateway can be provided only if common
745 formats are supported. Specification of those common formats is out
746 of scope for this document, although it is suggested to use [RFC3862]
747 for instant messages.
749 11. References
751 11.1. Normative References
753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
754 Requirement Levels", BCP 14, RFC 2119, March 1997.
756 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
757 A., Peterson, J., Sparks, R., Handley, M., and E.
758 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
759 June 2002.
761 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
762 Messaging (CPIM): Message Format", RFC 3862, August 2004.
764 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
765 Instant Messaging", RFC 3994, January 2005.
767 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
768 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
770 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
771 Protocol (XMPP): Core", RFC 6120, March 2011.
773 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
774 Protocol (XMPP): Instant Messaging and Presence", RFC
775 6121, March 2011.
777 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
778 "Interworking between the Session Initiation Protocol
779 (SIP) and the Extensible Messaging and Presence Protocol
780 (XMPP): Architecture, Addresses, and Error Handling", RFC
781 7247, May 2014.
783 [XEP-0085]
784 Saint-Andre, P. and D. Smith, "Chat State Notifications",
785 XSF XEP 0085, September 2009.
787 [XEP-0184]
788 Saint-Andre, P. and J. Hildebrand, "Message Delivery
789 Receipts", XSF XEP 0184, March 2011.
791 11.2. Informative References
793 [I-D.ietf-stox-im]
794 Saint-Andre, P., Houri, A., and J. Hildebrand,
795 "Interworking between the Session Initiation Protocol
796 (SIP) and the Extensible Messaging and Presence Protocol
797 (XMPP): Instant Messaging", draft-ietf-stox-im-10 (work in
798 progress), August 2014.
800 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
801 / Presence Protocol Requirements", RFC 2779, February
802 2000.
804 Appendix A. Acknowledgements
806 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an
807 early version of this document.
809 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu,
810 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for
811 their feedback.
813 The authors gratefully acknowledge the assistance of Markus Isomaki
814 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
815 and Alissa Cooper as the sponsoring Area Directors.
817 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
818 employing him during his work on earlier versions of this document.
820 Authors' Addresses
821 Peter Saint-Andre
822 &yet
824 Email: peter@andyet.com
825 URI: https://andyet.com/
827 Salvatore Loreto
828 Ericsson
829 Hirsalantie 11
830 Jorvas 02420
831 Finland
833 Email: Salvatore.Loreto@ericsson.com