idnits 2.17.1
draft-ietf-stox-chat-10.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 13, 2015) is 3360 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 (-13) exists of draft-ietf-stox-im-12
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0085'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0184'
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 17, 2015 Ericsson
6 February 13, 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-10
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 17, 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 . . . . . . . . . . . . . . . . . . . . . . 14
63 8. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 16
64 9. Internationalization Considerations . . . . . . . . . . . . . 17
65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
71 1. Introduction
73 Both the Session Initiation Protocol (SIP) [RFC3261] and the
74 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be
75 used for the purpose of one-to-one text chat over the Internet. To
76 ensure interworking between these technologies, it is important to
77 define bidirectional protocol mappings.
79 The architectural assumptions underlying such protocol mappings are
80 provided in [RFC7247], including mapping of addresses and error
81 conditions. This document specifies mappings for one-to-one text
82 chat sessions (sometimes called "session-mode" messaging); in
83 particular, this document specifies mappings between XMPP messages of
84 type "chat" and the Message Session Relay Protocol (MSRP) [RFC4975],
85 which is commonly used in SIP-based systems for chat functionality
86 (although note that MSRP is not conjoined to SIP, and can be used by
87 non-SIP technologies). Mappings for single instant messages and
88 groupchat are provided in separate documents.
90 The approach taken here is to directly map syntax and semantics from
91 one protocol to another. The mapping described herein depends on the
92 protocols defined in the following specifications:
94 o XMPP chat sessions using message stanzas of type "chat" are
95 specified in [RFC6121].
97 o MSRP chat sessions using the SIP INVITE and SEND request types are
98 specified in [RFC4975].
100 In SIP-based systems that use MSRP, a chat session is formally
101 negotiated just as any other session type is using SIP. By contrast,
102 a one-to-one chat "session" in XMPP is an informal construct and is
103 not formally negotiated: a user simply sends a message of type "chat"
104 to a contact, the contact then replies to the message, and the sum
105 total of such messages exchanged during a defined period of time is
106 considered to be a chat session (ideally tied together using an XMPP
107 element as described in Section 5.1 of [RFC6121]). To
108 overcome the disparity between these approaches, a gateway that
109 wishes to map between SIP/MSRP and XMPP for one-to-one chat sessions
110 needs to maintain some additional state, as described below.
112 2. Intended Audience
114 The documents in this series are intended for use by software
115 developers who have an existing system based on one of these
116 technologies (e.g., SIP), and would like to enable communication from
117 that existing system to systems based on the other technology (e.g.,
118 XMPP). We assume that readers are familiar with the core
119 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
120 base document for this series [RFC7247], and with the following chat-
121 related specifications:
123 o The Message Session Relay Protocol (MSRP) [RFC4975]
125 o Extensible Messaging and Presence Protocol: Instant Messaging and
126 Presence [RFC6121]
128 o Indication of Message Composition for Instant Messaging [RFC3994]
130 o Chat State Notifications [XEP-0085]
132 Note well that not all protocol-compliant messages are shown (such as
133 SIP 100 TRYING messages), in order to focus the reader on the
134 essential aspects of the protocol flows.
136 3. Terminology
138 A number of terms used here are explained in [RFC3261], [RFC4975],
139 [RFC6120], and [RFC6121].
141 In flow diagrams, SIP/MSRP traffic is shown using arrows such as
142 "***>" whereas XMPP traffic is shown using arrows such as "...>".
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
146 "OPTIONAL" in this document are to be interpreted as described in
147 [RFC2119].
149 4. XMPP to MSRP
151 In XMPP, the "informal session" approach is to simply send someone a
152 of type "chat" without starting any session negotiation
153 ahead of time (as described in [RFC6121]). The XMPP "informal
154 session" approach maps very well into a SIP MESSAGE request, as
155 described in [RFC7247]. However, the XMPP informal session approach
156 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains
157 additional state. The order of events is as follows.
159 XMPP XMPP XMPP-to-MSRP SIP SIP
160 User Server Gateway Server User
161 | | | | |
162 | (F1) XMPP | | | |
163 | message | | | |
164 |..............>| | | |
165 | | (F2) XMPP | | |
166 | | message | | |
167 | |..............>| | |
168 | | | (F3) SIP | |
169 | | | INVITE | |
170 | | |**************>| |
171 | | | | (F4) SIP |
172 | | | | INVITE |
173 | | | |**************>|
174 | | | | (F5) SIP |
175 | | | | 200 OK |
176 | | | |<**************|
177 | | | (F6) SIP | |
178 | | | 200 OK | |
179 | | |<**************| |
180 | | | (F7) SIP ACK | |
181 | | |**************>| |
182 | | | | (F8) SIP ACK |
183 | | | |**************>|
184 | | | (F9) MSRP SEND |
185 | | |******************************>|
186 . . . . .
187 . . . . .
188 | | | (F10) MSRP SEND |
189 | | |<******************************|
190 | | (F11) XMPP | | |
191 | | message | | |
192 | |<..............| | |
193 | (F12) XMPP | | | |
194 | message | | | |
195 |<..............| | | |
196 . . . . .
197 . . . . .
198 | | | | (F13) SIP BYE |
199 | | | |<**************|
200 | | | (F14) SIP BYE | |
201 | | |<**************| |
202 | | | (F15) SIP | |
203 | | | 200 OK | |
204 | | |**************>| |
205 | | | | (F16) SIP |
206 | | | | 200 OK |
207 | | | |**************>|
209 Figure 1: XMPP to MSRP Order of Events
211 The mapping of XMPP syntax to SIP syntax MUST be as specified in
212 [I-D.ietf-stox-im].
214 First the XMPP user would generate an XMPP chat message.
216 Example 1: Juliet sends XMPP message (F1)
218 |
222 | 29377446-0CBB-4296-8958-590D79094C50
223 | Art thou not Romeo, and a Montague?
224 |
226 Upon receiving such a message stanza, the XMPP server needs to
227 determine the identity of the domainpart in the 'to' address, which
228 it does by following the procedures explained in Section 5 of
229 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand
230 off the message stanza to an XMPP-to-SIP gateway or connection
231 manager that natively communicates with MSRP-aware SIP servers.
233 The XMPP-to-SIP gateway at the XMPP server would then initiate an
234 MSRP session with Romeo on Juliet's behalf (since there is no
235 reliable way for the gateway to determine whether Romeo's client
236 supports MSRP, if that is not the case then MSRP session initiation
237 might result in an error).
239 Example 2: Gateway starts SIP session on behalf of Juliet (F3)
241 | INVITE sip:romeo@example.net SIP/2.0
242 | To:
243 | From:
244 | Contact: ;gr=yn0cl4bnw0yr3vym
245 | Subject: Open chat with Juliet?
246 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
247 | CSeq: 1 INVITE
248 | Content-Type: application/sdp
249 |
250 | c=IN IP4 x2s.example.com
251 | m=message 7654 TCP/MSRP *
252 | a=accept-types:text/plain
253 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
255 Here we assume that Romeo's client supports MSRP and that Romeo
256 accepts the MSRP session request.
258 Example 3: Romeo accepts session request (F5)
260 | SIP/2.0 200 OK
261 | From:
262 | To:
263 | Contact: ;gr=dr4hcr0st3lup4c
264 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
265 | CSeq: 1 INVITE
266 | Content-Type: application/sdp
267 |
268 | c=IN IP4 s2x.example.net
269 | m=message 12763 TCP/MSRP *
270 | a=accept-types:text/plain
271 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
273 The XMPP-to-SIP gateway then acknowledges the session acceptance on
274 behalf of Juliet.
276 Example 4: Gateway sends ACK to Romeo (F7)
278 | ACK sip:juliet@example.com SIP/2.0
279 | To: ;gr=dr4hcr0st3lup4c
280 | From:
281 | Contact: ;gr=yn0cl4bnw0yr3vym
282 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
283 | CSeq: 2 ACK
285 The XMPP-to-SIP gateway then transforms the original XMPP chat
286 message into MSRP.
288 Example 5: Gateway maps XMPP message to MSRP (F9)
290 | MSRP a786hjs2 SEND
291 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
292 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
293 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A
294 | Byte-Range: 1-25/25
295 | Content-Type: text/plain
296 |
297 | Art thou not Romeo, and a Montague?
298 | -------a786hjs2$
300 Romeo can then send a reply using his MSRP client.
302 Example 6: Romeo sends reply (F10)
304 | MSRP di2fs53v SEND
305 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
306 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
307 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA
308 | Byte-Range: 1-25/25
309 | Failure-Report: no
310 | Content-Type: text/plain
311 |
312 | Neither, fair saint, if either thee dislike.
313 | -------di2fs53v$
315 The SIP-to-XMPP gateway would then transform that message into
316 appropriate XMPP syntax for routing to the intended recipient.
318 Example 7: Gateway maps MSRP message to XMPP (F11)
320 |
324 | 29377446-0CBB-4296-8958-590D79094C50
325 | Neither, fair saint, if either thee dislike.
326 |
328 When the MSRP user wishes to end the chat session, the user's MSRP
329 client sends a SIP BYE.
331 Example 8: Romeo terminates chat session (F13)
333 | BYE juliet@example.com sip: SIP/2.0
334 | From: ;tag=786
335 | To: ;tag=087js
336 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
337 | CSeq: 3 BYE
338 | Content-Length: 0
340 The BYE is then acknowledged by the XMPP-to-SIP gateway.
342 Example 9: Gateway acknowledges termination (F15)
344 | SIP/2.0 200 OK
345 | From: ;tag=786
346 | To: ;tag=087js
347 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
348 | CSeq: 3 BYE
349 | Content-Length: 0
351 Because there is no formal session on the XMPP side, there is no
352 corresponding communication from the gateway to the XMPP user.
353 However, it is reasonable for the gateway to send a "gone" chat state
354 notification [XEP-0085], as described under Section 6.1.
356 In addition, there is no explicit method defined in [RFC6121] for an
357 XMPP user to formally terminate a chat session, so a gateway would
358 need to listen for a "gone" chat state notification from the XMPP
359 user or institute a timer that considers the XMPP informal chat
360 session to be ended after some amount of time has elapsed.
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 specified in
422 [I-D.ietf-stox-im].
424 The protocol flow begins when Romeo starts a chat session with
425 Juliet.
427 Example 10: Romeo starts chat session (F17)
429 | INVITE sip:juliet@example.com SIP/2.0
430 | From:
431 | To:
432 | Contact: ;gr=dr4hcr0st3lup4c
433 | Subject: Open chat with Romeo?
434 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
435 | CSeq: 1 INVITE
436 | Content-Type: application/sdp
437 |
438 | c=IN IP4 s2x.example.net
439 | m=message 7313 TCP/MSRP *
440 | a=accept-types:text/plain
441 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
443 Upon receiving the INVITE, the SIP (MSRP) server needs to determine
444 the identity of the domain portion of the Request-URI or To header,
445 which it does by following the procedures explained in Section 5 of
446 [RFC7247]. If the domain is an XMPP domain, the SIP server will hand
447 off the INVITE to an associated MSRP-to-XMPP gateway or connection
448 manager that natively communicates with XMPP servers.
450 Example 11: Gateway accepts session on Juliet's behalf (F19)
452 | SIP/2.0 200 OK
453 | From: ;gr=dr4hcr0st3lup4c
454 | To:
455 | Contact: ;gr=yn0cl4bnw0yr3vym
456 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
457 | CSeq: 1 INVITE
458 | Content-Type: application/sdp
459 |
460 | c=IN IP4 x2s.example.com
461 | m=message 8763 TCP/MSRP *
462 | a=accept-types:text/plain
463 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
465 Example 12: Romeo sends ACK (F21)
467 | ACK sip:juliet@example.com SIP/2.0
468 | To: ;gr=yn0cl4bnw0yr3vym
469 | From:
470 | Contact: ;gr=dr4hcr0st3lup4c
471 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
472 | CSeq: 2 ACK
473 Example 13: Romeo sends message (F23)
475 | MSRP ad49kswow SEND
476 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
477 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
478 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
479 | Byte-Range: 1-32/32
480 | Failure-Report: no
481 | Content-Type: text/plain
482 |
483 | I take thee at thy word ...
484 | -------ad49kswow$
486 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24)
488 |
492 | F6989A8C-DE8A-4E21-8E07-F0898304796F
493 | I take thee at thy word ...
494 |
496 Example 15: Juliet sends reply (F26)
498 |
502 | 29377446-0CBB-4296-8958-590D79094C50
503 | What man art thou ...?
504 |
506 Example 16: Gateway maps XMPP message to MSRP (F28)
508 | MSRP ms53b7z9 SEND
509 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
510 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
511 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
512 | Byte-Range: 1-25/25
513 | Failure-Report: no
514 | Content-Type: text/plain
515 |
516 | What man art thou ...?
517 | -------ms53b7z9$
518 Example 17: Romeo terminates chat session (F29)
520 | BYE juliet@example.com sip: SIP/2.0
521 | To: ;gr=yn0cl4bnw0yr3vym
522 | From:
523 | Contact: ;gr=dr4hcr0st3lup4c
524 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
525 | CSeq: 3 BYE
526 | Content-Length: 0
528 Example 18: Gateway acknowledges termination of session on behalf of
529 Juliet (F31)
531 | SIP/2.0 200 OK
532 | To: ;gr=yn0cl4bnw0yr3vym
533 | From:
534 | Contact: ;gr=dr4hcr0st3lup4c
535 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
536 | CSeq: 3 BYE
538 6. Composing Events
540 Both XMPP and MSRP enable a client to receive notifications when a
541 person's conversation partner is composing an instant message within
542 the context of a chat session.
544 For XMPP, the Chat State Notifications specification [XEP-0085]
545 defines five states: active, inactive, gone, composing, and paused.
546 Some of these states are related to the act of message composition
547 (composing, paused), whereas others are related to the sender's
548 involvement with the chat session (active, inactive, gone). Note
549 that the "gone" chat state is not to be confused with the
550 stanza error condition defined in [RFC6120].
552 For MSRP (and SIP/SIMPLE in general), the Indication of Message
553 Composition for Instant Messaging specification [RFC3994] defines two
554 states: idle and active. Here the idle state indicates that the
555 sender is not actively composing a message, and the active state
556 indicates that the sender is indeed actively composing a message (the
557 sending client simply toggles between the two states, changing to
558 active if the user is actively composing a message and changing to
559 idle if the user is no longer actively composing a message).
561 Because the XEP-0085 states can represent information that is not
562 captured in RFC 3994, gateways can either (a) map only the composing-
563 related states or (b) map all the XEP-0085 states.
565 The following mappings are suggested.
567 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states
569 +-------------------+--------------------+
570 | isComposing Event | Chat State |
571 +-------------------+--------------------+
572 | active | composing |
573 | idle | active |
574 +-------------------+--------------------+
576 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events
578 +-------------------+--------------------+
579 | Chat State | isComposing Event |
580 +-------------------+--------------------+
581 | active | idle |
582 | inactive | idle |
583 | gone | [none, see note] |
584 | composing | active |
585 | paused | idle |
586 +-------------------+--------------------+
588 6.1. Use of the Gone Chat State
590 Although there is no direct mapping for the "gone" chat state to an
591 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP
592 gateway can serve as a trigger for terminating the formal chat
593 session within MSRP, i.e., for sending a SIP BYE for the session from
594 the XMPP-to-MSRP gateway to the SIP user. The following examples
595 illustrate this indirect mapping (which would occur after step F14 in
596 Figure 1).
598 Example 19: Juliet sends gone chat state
600 |
604 | 29377446-0CBB-4296-8958-590D79094C50
605 |
606 |
607 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE
609 | BYE romeo@example.net sip: SIP/2.0
610 | From: ;tag=786
611 | To: ;tag=087js
612 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
613 | CSeq: 3 BYE
614 | Content-Length: 0
616 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway
617 can serve as a trigger for sending a "gone" chat state notification
618 to the XMPP user. The following examples illustrate this indirect
619 mapping (which would occur after step F30 in Figure 2).
621 Example 21: Romeo terminates chat session
623 | BYE juliet@example.com sip: SIP/2.0
624 | To: ;gr=yn0cl4bnw0yr3vym
625 | From:
626 | Contact: ;gr=dr4hcr0st3lup4c
627 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
628 | CSeq: 3 BYE
629 | Content-Length: 0
631 Example 22: MSRP-to-XMPP gateway generates gone chat state
633 |
637 | F6989A8C-DE8A-4E21-8E07-F0898304796F
638 |
639 |
641 To enable these uses, gateways that support chat state notifications
642 MUST support the "gone" state (which is merely recommended, not
643 required, by [XEP-0085]).
645 It is also reasonable for gateways to implement timers that
646 automatically trigger a "gone" chat state if the XMPP user has not
647 sent a message within the "session" for a given amount of time.
649 7. Delivery Reports
651 Both XMPP and MSRP enable a client to receive notifications when a
652 message has been received by the intended recipient.
654 For XMPP, the Message Receipts specification [XEP-0184] defines a
655 method and XML namespace for requesting and returning indications
656 that a message has been received by a client controlled by the
657 intended recipient.
659 For MSRP, a native reporting feature is included, in the form of
660 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
662 An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report
664 header field with a value of "yes", and an XMPP Message Receipts
665 element of is to be mapped to
666 an MSRP REPORT request.
668 A Success-Report header field with a value of "yes" in an MSRP SEND
669 request is to be mapped to an XMPP Message Receipts element of
670 , and an MSRP REPORT request is
671 to be mapped to an XMPP message containing only a Message Receipts
672 element of .
674 Because the XMPP Message Receipts specification does not support
675 failure reports, there is no mapping for the MSRP Failure-Report
676 header field and gateways SHOULD set that header field to "no".
678 Examples follow.
680 First, the XMPP user sends a message containing a request for
681 delivery notification.
683 Example 23: Juliet sends XMPP message with receipt request
685 |
689 | 29377446-0CBB-4296-8958-590D79094C50
690 | What man art thou ...?
691 |
692 |
693 Example 24: Gateway maps XMPP message to MSRP
695 | MSRP bf9m36d5 SEND
696 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
697 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
698 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
699 | Byte-Range: 1-25/25
700 | Success-Report: yes
701 | Failure-Report: no
702 | Content-Type: text/plain
703 |
704 | What man art thou ...?
705 | -------bf9m36d5$
707 Next, the recipient returns a report.
709 Example 25: Romeo returns MSRP receipt
711 | MSRP hx74g336 REPORT
712 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
713 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
714 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
715 | Byte-Range: 1-106/106
716 | Status: 000 200 OK
717 | -------hx74g336$
719 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP
721 |
724 |
725 |
727 8. Message Size
729 Unlike page-mode messaging [RFC3428] (which specifies that the size
730 of a MESSAGE request is not allowed to exceed 1300 bytes), session-
731 mode messaging [RFC4975] can be used to send larger messages. MSRP
732 includes a chunking mechanism such that larger messages can be broken
733 up into multiple MSRP SEND requests. Because the MSRP gateway at an
734 XMPP service acts as an MSRP endpoint, it is responsible for
735 receiving chunked messages and reconstructing them into a single
736 message for delivery toward the XMPP recipient. (Naturally,
737 implementations need to be careful about accepting very large
738 messages; see Section 14.5 of [RFC4975].)
739 Although there is no hard limit on the size of an XMPP stanza, in
740 practice most XMPP services (at least on the public Internet) are
741 configured with a maximum stanza size in order to help prevent denial
742 of service attacks. As specified in Section 13.12 of [RFC6120], this
743 maximum is not allowed to be less than 10,000 bytes.
745 The administrators of an XMPP service need to ensure that the
746 associated MSRP gateway is configured with the same or smaller
747 maximum MSRP message size as the maximum XMPP stanza size; this
748 enables the gateway to return an appropriate value for the SDP "max-
749 size" attribute (see Section 8.6 of [RFC4975]) and to properly handle
750 incoming messages larger than the configured limits.
752 If an MSRP-to-XMPP gateway implementation receives an MSRP message
753 that exceeds its configured limit as just described, it MUST return
754 an MSRP 413 error (e.g., in response to the first SEND request whose
755 Byte-Range header field indicates a byte total exceeding the limit).
757 9. Internationalization Considerations
759 Relevant discussion of internationalized text in messages can be
760 found in [I-D.ietf-stox-im].
762 10. IANA Considerations
764 This document requests no actions of IANA.
766 11. Security Considerations
768 Detailed security considerations for instant messaging protocols are
769 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261]
770 when SIP is used to negotiate MSRP sessions), and for XMPP-based
771 instant messaging in [RFC6121] (see also [RFC6120]). The security
772 considerations provided in [RFC7247] also apply.
774 This document specifies methods for exchanging instant messages
775 through a gateway that translates between SIP/MSRP and XMPP. Such a
776 gateway MUST be compliant with the minimum security requirements of
777 the textual chat protocols for which it translates (i.e., MSRP and
778 XMPP). The addition of gateways to the security model of instant
779 messaging specified in [RFC2779] introduces some new risks. In
780 particular, end-to-end security properties (especially
781 confidentiality and integrity) between instant messaging clients that
782 interface through an MSRP-XMPP gateway can be provided only if common
783 formats are supported. Although specification of those common
784 formats is out of scope for this document, for instant messages it is
785 possible to use [RFC3862] (see also [RFC3923]).
787 12. References
789 12.1. Normative References
791 [I-D.ietf-stox-im]
792 Saint-Andre, P., Houri, A., and J. Hildebrand,
793 "Interworking between the Session Initiation Protocol
794 (SIP) and the Extensible Messaging and Presence Protocol
795 (XMPP): Instant Messaging", draft-ietf-stox-im-12 (work in
796 progress), February 2015.
798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
799 Requirement Levels", BCP 14, RFC 2119, March 1997.
801 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
802 A., Peterson, J., Sparks, R., Handley, M., and E.
803 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
804 June 2002.
806 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
807 Messaging (CPIM): Message Format", RFC 3862, August 2004.
809 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
810 Instant Messaging", RFC 3994, January 2005.
812 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
813 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
815 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
816 Protocol (XMPP): Core", RFC 6120, March 2011.
818 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
819 Protocol (XMPP): Instant Messaging and Presence", RFC
820 6121, March 2011.
822 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
823 "Interworking between the Session Initiation Protocol
824 (SIP) and the Extensible Messaging and Presence Protocol
825 (XMPP): Architecture, Addresses, and Error Handling", RFC
826 7247, May 2014.
828 [XEP-0085]
829 Saint-Andre, P. and D. Smith, "Chat State Notifications",
830 XSF XEP 0085, September 2009.
832 [XEP-0184]
833 Saint-Andre, P. and J. Hildebrand, "Message Delivery
834 Receipts", XSF XEP 0184, March 2011.
836 12.2. Informative References
838 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
839 / Presence Protocol Requirements", RFC 2779, February
840 2000.
842 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
843 and D. Gurle, "Session Initiation Protocol (SIP) Extension
844 for Instant Messaging", RFC 3428, December 2002.
846 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
847 for the Extensible Messaging and Presence Protocol
848 (XMPP)", RFC 3923, October 2004.
850 Appendix A. Acknowledgements
852 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an
853 early version of this document.
855 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu,
856 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for
857 their feedback.
859 The authors gratefully acknowledge the assistance of Markus Isomaki
860 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
861 and Alissa Cooper as the sponsoring Area Directors.
863 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
864 employing him during his work on earlier versions of this document.
866 Authors' Addresses
868 Peter Saint-Andre
869 &yet
871 Email: peter@andyet.com
872 URI: https://andyet.com/
874 Salvatore Loreto
875 Ericsson
876 Hirsalantie 11
877 Jorvas 02420
878 Finland
880 Email: Salvatore.Loreto@ericsson.com