idnits 2.17.1
draft-ietf-stox-chat-11.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 (March 5, 2015) is 3340 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'
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 6, 2015 Ericsson
6 March 5, 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-11
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 September 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. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 17
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 negotiated when using
102 SIP). By contrast, a one-to-one chat "session" in XMPP is an
103 informal construct and is not formally negotiated: a user simply
104 sends a message of type "chat" to a contact, the contact then replies
105 to the message, and the sum total of such messages exchanged during a
106 defined period of time is considered to be a chat session (ideally
107 tied together using an XMPP element as described in
108 Section 5.1 of [RFC6121]). To overcome the disparity between these
109 approaches, a gateway that wishes to map between SIP/MSRP and XMPP
110 for one-to-one chat sessions needs to maintain some additional state,
111 as described below.
113 2. Intended Audience
115 The documents in this series are intended for use by software
116 developers who have an existing system based on one of these
117 technologies (e.g., SIP), and would like to enable communication from
118 that existing system to systems based on the other technology (e.g.,
119 XMPP). We assume that readers are familiar with the core
120 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
121 base document for this series [RFC7247], and with the following chat-
122 related specifications:
124 o The Message Session Relay Protocol (MSRP) [RFC4975]
126 o Extensible Messaging and Presence Protocol: Instant Messaging and
127 Presence [RFC6121]
129 o Indication of Message Composition for Instant Messaging [RFC3994]
131 o Chat State Notifications [XEP-0085]
133 Note well that not all protocol-compliant messages are shown (such as
134 SIP 100 TRYING messages), in order to focus the reader on the
135 essential aspects of the protocol flows.
137 3. Terminology
139 A number of terms used here are explained in [RFC3261], [RFC4975],
140 [RFC6120], and [RFC6121].
142 In flow diagrams, SIP/MSRP traffic is shown using arrows such as
143 "***>" whereas XMPP traffic is shown using arrows such as "...>".
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
147 "OPTIONAL" in this document are to be interpreted as described in
148 [RFC2119].
150 4. XMPP to MSRP
152 In XMPP, the "informal session" approach is to simply send someone a
153 of type "chat" without starting any session negotiation
154 ahead of time (as described in [RFC6121]). The XMPP "informal
155 session" approach maps very well into a SIP MESSAGE request, as
156 described in [RFC7247]. However, the XMPP informal session approach
157 can also be mapped to MSRP if the XMPP-to-SIP gateway maintains
158 additional state. The order of events is as follows.
160 XMPP XMPP XMPP-to-MSRP SIP SIP
161 User Server Gateway Server User
162 | | | | |
163 | (F1) XMPP | | | |
164 | message | | | |
165 |..............>| | | |
166 | | (F2) XMPP | | |
167 | | message | | |
168 | |..............>| | |
169 | | | (F3) SIP | |
170 | | | INVITE | |
171 | | |**************>| |
172 | | | | (F4) SIP |
173 | | | | INVITE |
174 | | | |**************>|
175 | | | | (F5) SIP |
176 | | | | 200 OK |
177 | | | |<**************|
178 | | | (F6) SIP | |
179 | | | 200 OK | |
180 | | |<**************| |
181 | | | (F7) SIP ACK | |
182 | | |**************>| |
183 | | | | (F8) SIP ACK |
184 | | | |**************>|
185 | | | (F9) MSRP SEND |
186 | | |******************************>|
187 . . . . .
188 . . . . .
189 | | | (F10) MSRP SEND |
190 | | |<******************************|
191 | | (F11) XMPP | | |
192 | | message | | |
193 | |<..............| | |
194 | (F12) XMPP | | | |
195 | message | | | |
196 |<..............| | | |
197 . . . . .
198 . . . . .
199 | | | | (F13) SIP BYE |
200 | | | |<**************|
201 | | | (F14) SIP BYE | |
202 | | |<**************| |
203 | | | (F15) SIP | |
204 | | | 200 OK | |
205 | | |**************>| |
206 | | | | (F16) SIP |
207 | | | | 200 OK |
208 | | | |**************>|
210 Figure 1: XMPP to MSRP Order of Events
212 The mapping of XMPP syntax to SIP syntax MUST be as specified in
213 [I-D.ietf-stox-im].
215 First the XMPP user would generate an XMPP chat message.
217 Example 1: Juliet sends XMPP message (F1)
219 |
223 | 29377446-0CBB-4296-8958-590D79094C50
224 | Art thou not Romeo, and a Montague?
225 |
227 Upon receiving such a message stanza, the XMPP server needs to
228 determine the identity of the domainpart in the 'to' address, which
229 it does by following the procedures explained in Section 5 of
230 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand
231 off the message stanza to an XMPP-to-SIP gateway or connection
232 manager that natively communicates with MSRP-aware SIP servers.
234 The XMPP-to-SIP gateway at the XMPP server would then initiate an
235 MSRP session with Romeo on Juliet's behalf (since there is no
236 reliable way for the gateway to determine whether Romeo's client
237 supports MSRP, if that is not the case then MSRP session initiation
238 might result in an error).
240 Example 2: Gateway starts SIP session on behalf of Juliet (F3)
242 | INVITE sip:romeo@example.net SIP/2.0
243 | To:
244 | From:
245 | Contact: ;gr=yn0cl4bnw0yr3vym
246 | Subject: Open chat with Juliet?
247 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
248 | CSeq: 1 INVITE
249 | Content-Type: application/sdp
250 |
251 | c=IN IP4 x2s.example.com
252 | m=message 7654 TCP/MSRP *
253 | a=accept-types:text/plain
254 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
256 Here we assume that Romeo's client supports MSRP and that Romeo
257 accepts the MSRP session request.
259 Example 3: Romeo accepts session request (F5)
261 | SIP/2.0 200 OK
262 | From:
263 | To:
264 | Contact: ;gr=dr4hcr0st3lup4c
265 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
266 | CSeq: 1 INVITE
267 | Content-Type: application/sdp
268 |
269 | c=IN IP4 s2x.example.net
270 | m=message 12763 TCP/MSRP *
271 | a=accept-types:text/plain
272 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
274 The XMPP-to-SIP gateway then acknowledges the session acceptance on
275 behalf of Juliet.
277 Example 4: Gateway sends ACK to Romeo (F7)
279 | ACK sip:juliet@example.com SIP/2.0
280 | To: ;gr=dr4hcr0st3lup4c
281 | From:
282 | Contact: ;gr=yn0cl4bnw0yr3vym
283 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
284 | CSeq: 2 ACK
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=786
336 | To: ;tag=087js
337 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
338 | CSeq: 3 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: 3 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 In addition, there is no explicit method defined in [RFC6121] for an
358 XMPP user to formally terminate a chat session, so a gateway would
359 need to listen for a "gone" chat state notification from the XMPP
360 user or institute a timer that considers the XMPP informal chat
361 session to be ended after some amount of time has elapsed ([XEP-0085]
362 suggests generating a "gone" chat state if a user has not interacted
363 with the chat session interface, system, or device for a relatively
364 long period of time, e.g., 10 minutes).
366 5. MSRP to XMPP
368 When an MSRP client sends messages through a gateway to an XMPP
369 client, the order of events is as follows.
371 SIP SIP MSRP-to-XMPP XMPP XMPP
372 User Server Gateway Server User
373 | | | | |
374 | (F17) SIP | | | |
375 | INVITE | | | |
376 |**************>| | | |
377 | | (F18) SIP | | |
378 | | INVITE | | |
379 | |**************>| | |
380 | | (F19) SIP | | |
381 | | 200 OK | | |
382 | |<**************| | |
383 | (F20) SIP | | | |
384 | 200 OK | | | |
385 |<**************| | | |
386 | (F21) SIP ACK | | | |
387 |**************>| | | |
388 | | (F22) SIP ACK | | |
389 | |**************>| | |
390 | (F23) MSRP SEND | | |
391 |******************************>| | |
392 | | | (F24) XMPP | |
393 | | | message | |
394 | | |..............>| |
395 | | | | (F25) XMPP |
396 | | | | message |
397 | | | |..............>|
398 . . . . .
399 . . . . .
400 | | | | (F26) XMPP |
401 | | | | message |
402 | | | |<..............|
403 | | | (F27) XMPP | |
404 | | | message | |
405 | | |<..............| |
406 | (F28) MSRP SEND | | |
407 |<******************************| | |
408 . . . . .
409 . . . . .
410 | | | | |
411 | | | | |
412 | (F29) SIP BYE | | | |
413 |**************>| | | |
414 | | (F30) SIP BYE | | |
415 | |**************>| | |
416 | | (F31) SIP | | |
417 | | 200 OK | | |
418 | |<**************| | |
419 | (F32) SIP | | | |
420 | 200 OK | | | |
421 |<**************| | | |
423 Figure 2: MSRP to XMPP Order of Events
425 The mapping of SIP syntax to XMPP syntax MUST be as specified in
426 [I-D.ietf-stox-im].
428 The protocol flow begins when Romeo starts a chat session with
429 Juliet.
431 Example 10: Romeo starts chat session (F17)
433 | INVITE sip:juliet@example.com SIP/2.0
434 | From:
435 | To:
436 | Contact: ;gr=dr4hcr0st3lup4c
437 | Subject: Open chat with Romeo?
438 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
439 | CSeq: 1 INVITE
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 | From: ;gr=dr4hcr0st3lup4c
458 | To:
459 | Contact: ;gr=yn0cl4bnw0yr3vym
460 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
461 | CSeq: 1 INVITE
462 | Content-Type: application/sdp
463 |
464 | c=IN IP4 x2s.example.com
465 | m=message 8763 TCP/MSRP *
466 | a=accept-types:text/plain
467 | 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=yn0cl4bnw0yr3vym
472 | From:
473 | Contact: ;gr=dr4hcr0st3lup4c
474 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
475 | CSeq: 2 ACK
477 Example 13: Romeo sends message (F23)
479 | MSRP ad49kswow SEND
480 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
481 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
482 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
483 | Byte-Range: 1-32/32
484 | Failure-Report: no
485 | Content-Type: text/plain
486 |
487 | I take thee at thy word ...
488 | -------ad49kswow$
490 Example 14: MSRP-to-XMPP gateway maps MSRP message to XMPP (F24)
492 |
496 | F6989A8C-DE8A-4E21-8E07-F0898304796F
497 | I take thee at thy word ...
498 |
500 Example 15: Juliet sends reply (F26)
502 |
506 | 29377446-0CBB-4296-8958-590D79094C50
507 | What man art thou ...?
508 |
509 Example 16: Gateway maps XMPP message to MSRP (F28)
511 | MSRP ms53b7z9 SEND
512 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
513 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
514 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
515 | Byte-Range: 1-25/25
516 | Failure-Report: no
517 | Content-Type: text/plain
518 |
519 | What man art thou ...?
520 | -------ms53b7z9$
522 Example 17: Romeo terminates chat session (F29)
524 | BYE juliet@example.com sip: SIP/2.0
525 | To: ;gr=yn0cl4bnw0yr3vym
526 | From:
527 | Contact: ;gr=dr4hcr0st3lup4c
528 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
529 | CSeq: 3 BYE
530 | Content-Length: 0
532 Example 18: Gateway acknowledges termination of session on behalf of
533 Juliet (F31)
535 | SIP/2.0 200 OK
536 | To: ;gr=yn0cl4bnw0yr3vym
537 | From:
538 | Contact: ;gr=dr4hcr0st3lup4c
539 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
540 | CSeq: 3 BYE
542 6. Composing Events
544 Both XMPP and MSRP enable a client to receive notifications when a
545 person's conversation partner is composing an instant message within
546 the context of a chat session.
548 For XMPP, the Chat State Notifications specification [XEP-0085]
549 defines five states: active, inactive, gone, composing, and paused.
550 Some of these states are related to the act of message composition
551 (composing, paused), whereas others are related to the sender's
552 involvement with the chat session (active, inactive, gone). Note
553 that the "gone" chat state is not to be confused with the
554 stanza error condition defined in [RFC6120].
556 For MSRP (and SIP/SIMPLE in general), the Indication of Message
557 Composition for Instant Messaging specification [RFC3994] defines two
558 states: idle and active. Here the idle state indicates that the
559 sender is not actively composing a message, and the active state
560 indicates that the sender is indeed actively composing a message (the
561 sending client simply toggles between the two states).
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 S.6.1] |
586 | composing | active |
587 | paused | idle |
588 +-------------------+--------------------+
590 The XMPP Chat State Notifications specification [XEP-0085] allows the
591 sending of "standalone notifications" outside the context of a
592 message, theoretically even before any messages are exchanged;
593 although a gateway could thus send an notification to the
594 XMPP user when the SIP user accepts or initiates a chat session
595 (i.e., after F6 in Section 4 or after F22 in Section 5), this usage
596 might be unexpected by XMPP clients as a way to signal the beginning
597 of an informal chat session.
599 6.1. Use of the Gone Chat State
601 Although there is no direct mapping for the "gone" chat state to an
602 isComposing event, receipt of the "gone" state at an XMPP-to-MSRP
603 gateway can serve as a trigger for terminating the formal chat
604 session within MSRP, i.e., for sending a SIP BYE for the session from
605 the XMPP-to-MSRP gateway to the SIP user. The following examples
606 illustrate this indirect mapping (which would occur after step F14 in
607 Figure 1).
609 Example 19: Juliet sends gone chat state
611 |
615 | 29377446-0CBB-4296-8958-590D79094C50
616 |
617 |
619 Example 20: XMPP-to-MSRP gateway maps gone chat state to SIP BYE
621 | BYE romeo@example.net sip: SIP/2.0
622 | From: ;tag=786
623 | To: ;tag=087js
624 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
625 | CSeq: 3 BYE
626 | Content-Length: 0
628 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway
629 can serve as a trigger for sending a "gone" chat state notification
630 to the XMPP user. The following examples illustrate this indirect
631 mapping (which would occur after step F30 in Figure 2).
633 Example 21: Romeo terminates chat session
635 | BYE juliet@example.com sip: SIP/2.0
636 | To: ;gr=yn0cl4bnw0yr3vym
637 | From:
638 | Contact: ;gr=dr4hcr0st3lup4c
639 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
640 | CSeq: 3 BYE
641 | Content-Length: 0
643 Example 22: MSRP-to-XMPP gateway generates gone chat state
645 |
649 | F6989A8C-DE8A-4E21-8E07-F0898304796F
650 |
651 |
652 To enable these uses, gateways that support chat state notifications
653 MUST support the "gone" state (which is merely recommended, not
654 required, by [XEP-0085]).
656 It is also reasonable for gateways to implement timers that
657 automatically trigger a "gone" chat state if the XMPP user has not
658 sent a message within the "session" for a given amount of time
659 ([XEP-0085] suggests generating a "gone" chat state if a user has not
660 interacted with the chat session interface, system, or device for a
661 relatively long period of time, e.g., 10 minutes).
663 7. Delivery Reports
665 Both XMPP and MSRP enable a client to receive notifications when a
666 message has been received by the intended recipient.
668 For XMPP, the Message Receipts specification [XEP-0184] defines a
669 method and XML namespace for requesting and returning indications
670 that a message has been received by a client controlled by the
671 intended recipient.
673 For MSRP, a native reporting feature is included, in the form of
674 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
676 An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report
678 header field with a value of "yes", and an XMPP Message Receipts
679 element of is to be mapped to
680 an MSRP REPORT request.
682 A Success-Report header field with a value of "yes" in an MSRP SEND
683 request is to be mapped to an XMPP Message Receipts element of
684 , and an MSRP REPORT request is
685 to be mapped to an XMPP message containing only a Message Receipts
686 element of .
688 Because the XMPP Message Receipts specification does not support
689 failure reports, there is no mapping for the MSRP Failure-Report
690 header field and gateways SHOULD set that header field to "no".
692 Examples follow.
694 First, the XMPP user sends a message containing a request for
695 delivery notification.
697 Example 23: Juliet sends XMPP message with receipt request
699 |
703 | 29377446-0CBB-4296-8958-590D79094C50
704 | What man art thou ...?
705 |
706 |
708 Example 24: Gateway maps XMPP message to MSRP
710 | MSRP bf9m36d5 SEND
711 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
712 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
713 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
714 | Byte-Range: 1-25/25
715 | Success-Report: yes
716 | Failure-Report: no
717 | Content-Type: text/plain
718 |
719 | What man art thou ...?
720 | -------bf9m36d5$
722 Next, the recipient returns a report.
724 Example 25: Romeo returns MSRP receipt
726 | MSRP hx74g336 REPORT
727 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
728 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
729 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
730 | Byte-Range: 1-106/106
731 | Status: 000 200 OK
732 | -------hx74g336$
734 Example 26: MSRP-to-XMPP gateway maps receipt to XMPP
736 |
739 |
740 |
742 8. Message Size
744 Unlike page-mode messaging [RFC3428] (which specifies that the size
745 of a MESSAGE request is not allowed to exceed 1300 bytes), session-
746 mode messaging [RFC4975] can be used to send larger messages. MSRP
747 includes a chunking mechanism such that larger messages can be broken
748 up into multiple MSRP SEND requests. Because the MSRP gateway at an
749 XMPP service acts as an MSRP endpoint, it is responsible for
750 receiving chunked messages and reconstructing them into a single
751 message for delivery toward the XMPP recipient. (Naturally,
752 implementations need to be careful about accepting very large
753 messages; see Section 14.5 of [RFC4975].)
755 Although there is no hard limit on the size of an XMPP stanza, in
756 practice most XMPP services (at least on the public Internet) are
757 configured with a maximum stanza size in order to help prevent denial
758 of service attacks. As specified in Section 13.12 of [RFC6120], this
759 maximum is not allowed to be less than 10,000 bytes.
761 The administrators of an XMPP service need to ensure that the
762 associated MSRP gateway is configured with the same or smaller
763 maximum MSRP message size as the maximum XMPP stanza size; this
764 enables the gateway to return an appropriate value for the SDP "max-
765 size" attribute (see Section 8.6 of [RFC4975]) and to properly handle
766 incoming messages larger than the configured limits.
768 If an MSRP-to-XMPP gateway implementation receives an MSRP message
769 that exceeds its configured limit as just described, it MUST return
770 an MSRP 413 error (e.g., in response to the first SEND request whose
771 Byte-Range header field indicates a byte total exceeding the limit).
773 9. Internationalization Considerations
775 Relevant discussion of internationalized text in messages can be
776 found in [I-D.ietf-stox-im].
778 10. IANA Considerations
780 This document requests no actions of IANA.
782 11. Security Considerations
784 Detailed security considerations for instant messaging protocols are
785 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261]
786 when SIP is used to negotiate MSRP sessions), and for XMPP-based
787 instant messaging in [RFC6121] (see also [RFC6120]). The security
788 considerations provided in [RFC7247] also apply.
790 Considerations for end-to-end encryption of instant messages are
791 provided in [I-D.ietf-stox-im].
793 12. References
795 12.1. Normative References
797 [I-D.ietf-stox-im]
798 Saint-Andre, P., Houri, A., and J. Hildebrand,
799 "Interworking between the Session Initiation Protocol
800 (SIP) and the Extensible Messaging and Presence Protocol
801 (XMPP): Instant Messaging", draft-ietf-stox-im-13 (work in
802 progress), March 2015.
804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
805 Requirement Levels", BCP 14, RFC 2119, March 1997.
807 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
808 A., Peterson, J., Sparks, R., Handley, M., and E.
809 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
810 June 2002.
812 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
813 Instant Messaging", RFC 3994, January 2005.
815 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
816 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
818 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
819 Protocol (XMPP): Core", RFC 6120, March 2011.
821 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
822 Protocol (XMPP): Instant Messaging and Presence", RFC
823 6121, March 2011.
825 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
826 "Interworking between the Session Initiation Protocol
827 (SIP) and the Extensible Messaging and Presence Protocol
828 (XMPP): Architecture, Addresses, and Error Handling", RFC
829 7247, May 2014.
831 [XEP-0085]
832 Saint-Andre, P. and D. Smith, "Chat State Notifications",
833 XSF XEP 0085, September 2009.
835 [XEP-0184]
836 Saint-Andre, P. and J. Hildebrand, "Message Delivery
837 Receipts", XSF XEP 0184, March 2011.
839 12.2. Informative References
841 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
842 / Presence Protocol Requirements", RFC 2779, February
843 2000.
845 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
846 and D. Gurle, "Session Initiation Protocol (SIP) Extension
847 for Instant Messaging", RFC 3428, December 2002.
849 Appendix A. Acknowledgements
851 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an
852 early version of this document.
854 Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu,
855 Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for
856 their feedback.
858 Stephen Farrell, Brian Haberman, Joel Jaeggli, Barry Leiba, Kathleen
859 Moriarty, and Pete Resnick provided helpful input during IESG review.
861 The authors gratefully acknowledge the assistance of Markus Isomaki
862 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
863 and Alissa Cooper as the sponsoring Area Directors.
865 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
866 employing him during his work on earlier versions of this document.
868 Authors' Addresses
870 Peter Saint-Andre
871 &yet
873 Email: peter@andyet.com
874 URI: https://andyet.com/
876 Salvatore Loreto
877 Ericsson
878 Hirsalantie 11
879 Jorvas 02420
880 Finland
882 Email: Salvatore.Loreto@ericsson.com