idnits 2.17.1
draft-ietf-stox-chat-06.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 11, 2014) is 3698 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0085'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0184'
== Outdated reference: A later version (-13) exists of draft-ietf-stox-im-08
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Saint-Andre
3 Internet-Draft &yet
4 Intended status: Standards Track S. Loreto
5 Expires: September 12, 2014 Ericsson
6 March 11, 2014
8 Interworking between the Session Initiation Protocol (SIP) and the
9 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat
10 Sessions
11 draft-ietf-stox-chat-06
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 12, 2014.
39 Copyright Notice
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3
58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 4. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . 4
60 5. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . 8
61 6. Composing Events . . . . . . . . . . . . . . . . . . . . . . 12
62 7. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . 14
63 8. Internationalization Considerations . . . . . . . . . . . . . 16
64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
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 [I-D.ietf-stox-core], including mapping of addresses and
80 error conditions. This document specifies mappings for one-to-one
81 text 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 [I-D.ietf-stox-core], and with the
120 following chat-related specifications:
122 o The Message Session Relay Protocol (MSRP) [RFC4975]
124 o Extensible Messaging and Presence Protocol: Instant Messaging and
125 Presence [RFC6121]
127 o Indication of Message Composition for Instant Messaging [RFC3994]
129 o Chat State Notifications [XEP-0085]
131 3. Terminology
133 A number of terms used here are explained in [RFC3261], [RFC4975],
134 [RFC6120], and [RFC6121].
136 In flow diagrams, SIP/MSRP traffic is shown using arrows such as
137 "***>" whereas XMPP traffic is shown using arrows such as "...>".
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
141 "OPTIONAL" in this document are to be interpreted as described in
142 [RFC2119].
144 4. XMPP to MSRP
146 In XMPP, the "informal session" approach is to simply send someone a
147 of type "chat" without starting any session negotiation
148 ahead of time (as described in [RFC6121]). The XMPP "informal
149 session" approach maps very well into a SIP MESSAGE request, as
150 described in [I-D.ietf-stox-core]. However, the XMPP informal
151 session approach can also be mapped to MSRP if the XMPP-to-SIP
152 gateway maintains additional state.
154 The order of events is as follows.
156 XMPP XMPP XMPP-to-SIP SIP-to-XMPP SIP SIP
157 User Server Gateway Gateway Server User
158 | | | | | |
159 | (F1) XMPP | | | | |
160 | message | | | | |
161 |..........>| | | | |
162 | | (F2) XMPP | | | |
163 | | message | | | |
164 | |...........>| | | |
165 | | | (F3) SIP INVITE | |
166 | | |**************************>| |
167 | | | | | (F4) SIP |
168 | | | | | INVITE |
169 | | | | |*********>|
170 | | | | | (F5) SIP |
171 | | | | | 200 OK |
172 | | | | |<*********|
173 | | | | (F6) SIP | |
174 | | | | 200 OK | |
175 | | | |<***********| |
176 | | | | (F7) SIP | |
177 | | | | ACK | |
178 | | | |***********>| |
179 | | | | (F8) MSRP | |
180 | | | | SEND | |
181 | | | |***********>| |
182 | | | | | (F9) SIP |
183 | | | | | ACK |
184 | | | | |*********>|
185 | | | | |(F10) MSRP|
186 | | | | | SEND |
187 | | | | |*********>|
188 . . . . . .
189 . . . . . .
190 | | | | |(F11) MSRP|
191 | | | | | SEND |
192 | | | | |<*********|
193 | | | | (F12) MSRP | |
194 | | | | SEND | |
195 | | | |<***********| |
196 | | (F13) XMPP message | | |
197 | |<..........................| | |
198 |(F14) XMPP | | | | |
199 | message | | | | |
200 |<..........| | | | |
201 . . . . . .
202 . . . . . .
203 | | | | |(F15) SIP |
204 | | | | | BYE |
205 | | | | |<*********|
206 | | | | (F16) SIP | |
207 | | | | BYE | |
208 | | | |<***********| |
209 | | | | (F17) SIP | |
210 | | | | 200 OK | |
211 | | | |***********>| |
212 | | | | |(F18) SIP |
213 | | | | | 200 OK |
214 | | | | |*********>|
216 The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the
217 following table. (Mappings for several aspects not mentioned here
218 are specified in [I-D.ietf-stox-im].)
220 Table 1: Message syntax mapping from XMPP to SIP
222 +-----------------------------+--------------------------+
223 | XMPP Element or Attribute | SIP Header or Contents |
224 +-----------------------------+--------------------------+
225 | | Call-ID |
226 | id | transaction identifier |
227 +-----------------------------+--------------------------+
229 First the XMPP user would generate an XMPP chat message.
231 Example 1: Juliet sends XMPP message (F1)
233 |
237 | 29377446-0CBB-4296-8958-590D79094C50
238 | Art thou not Romeo, and a Montague?
239 |
240 Upon receiving such a message stanza, the XMPP server needs to
241 determine the identity of the domainpart in the 'to' address, which
242 it does by following the procedures explained in Section 5 of
243 [I-D.ietf-stox-core]. If the domain is a SIP domain, the XMPP server
244 will hand off the message stanza to an XMPP-to-SIP gateway or
245 connection manager that natively communicates with MSRP-aware SIP
246 servers.
248 The XMPP-to-SIP gateway at the XMPP server would then initiate an
249 MSRP session with Romeo on Juliet's behalf (since there is no
250 reliable way for the gateway to determine if Romeo's client supports
251 MSRP, it simply needs to guess).
253 Example 2: Gateway starts SIP session on behalf of Juliet (F3)
255 | INVITE sip:romeo@example.net SIP/2.0
256 | To:
257 | From:
258 | Contact: ;gr=balcony
259 | Subject: Open chat with Juliet?
260 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
261 | Content-Type: application/sdp
262 |
263 | c=IN IP4 x2s.example.com
264 | m=message 7654 TCP/MSRP *
265 | a=accept-types:text/plain
266 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
268 Here we assume that Romeo accepts the MSRP session request.
270 Example 3: Romeo accepts session request (F5)
272 | SIP/2.0 200 OK
273 | To:
274 | From:
275 | Contact: ;gr=orchard
276 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
277 | Content-Type: application/sdp
278 |
279 | c=IN IP4 s2x.example.net
280 | m=message 12763 TCP/MSRP *
281 | a=accept-types:text/plain
282 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
284 The XMPP-to-SIP gateway then acknowledges the session acceptance on
285 behalf of Juliet.
287 Example 4: Gateway sends ACK to Romeo (F7)
289 | ACK sip:juliet@example.com SIP/2.0
290 | To: ;gr=orchard
291 | From:
292 | Contact: ;gr=balcony
293 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
295 The XMPP-to-SIP gateway then transforms the original XMPP chat
296 message into MSRP.
298 Example 5: Gateway maps XMPP message to MSRP (F8)
300 | MSRP a786hjs2 SEND
301 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
302 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
303 | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A
304 | Byte-Range: 1-25/25
305 | Content-Type: text/plain
306 |
307 | Art thou not Romeo, and a Montague?
308 | -------a786hjs2$
310 Romeo can then send a reply using his MSRP client.
312 Example 6: Romeo sends reply (F11)
314 | MSRP di2fs53v SEND
315 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
316 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
317 | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA
318 | Byte-Range: 1-25/25
319 | Failure-Report: no
320 | Content-Type: text/plain
321 |
322 | Neither, fair saint, if either thee dislike.
323 | -------di2fs53v$
325 The SIP-to-XMPP gateway would then transform that message into
326 appropriate XMPP syntax for routing to the intended recipient.
328 Example 7: Gateway maps MSRP message to XMPP (F13)
330 |
334 | 29377446-0CBB-4296-8958-590D79094C50
335 | Neither, fair saint, if either thee dislike.
336 |
338 When the MSRP user wishes to end the chat session, the user's MSRP
339 client sends a SIP BYE.
341 Example 8: Romeo terminates chat session (F15)
343 | BYE juliet@example.com sip: SIP/2.0
344 | From: ;tag=087js
345 | To: ;tag=786
346 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
347 | Cseq: 1 BYE
348 | Content-Length: 0
350 The BYE is then acknowledged by the XMPP-to-SIP gateway.
352 Example 9: Gateway acknowledges termination (F17)
354 | SIP/2.0 200 OK
355 | From: ;tag=786
356 | To: ;tag=087js
357 | Call-ID: 29377446-0CBB-4296-8958-590D79094C50
358 | CSeq: 1 BYE
359 | Content-Length: 0
361 5. MSRP to XMPP
363 When an MSRP client sends messages through a gateway to an XMPP
364 client, the order of events is as follows.
366 SIP SIP SIP-to-XMPP XMPP-to-SIP XMPP XMPP
367 User Server Gateway Gateway Server User
368 | | | | | |
369 | (F19) SIP | | | | |
370 | INVITE | | | | |
371 |**********>| | | | |
372 | | (F20) SIP | | | |
373 | | INVITE | | | |
374 | |***********>| | | |
375 | | (F21) SIP | | | |
376 | | 200 OK | | | |
377 | |<***********| | | |
378 | (F22) SIP | | | | |
379 | 200 OK | | | | |
380 |<**********| | | | |
381 | (F23) SIP | | | | |
382 | ACK | | | | |
383 |**********>| | | | |
384 | (F24) MSRP| | | | |
385 | SEND | | | | |
386 |**********>| | | | |
387 | | (F25) SIP | | | |
388 | | ACK | | | |
389 | |***********>| | | |
390 | | (F26) MSRP | | | |
391 | | SEND | | | |
392 | |***********>| | | |
393 | | | (F27) XMPP message | |
394 | | |..........................>| |
395 | | | | | (F28) XMPP|
396 | | | | | message |
397 | | | | |..........>|
398 . . . . . .
399 . . . . . .
400 | | | | | (F29) XMPP|
401 | | | | | message |
402 | | | | |<..........|
403 | | | | (F30) XMPP | |
404 | | | | message | |
405 | | | |<...........| |
406 | | (F31) MSRP SEND | | |
407 | |<**************************| | |
408 | (F32) MSRP| | | | |
409 | SEND | | | | |
410 |<**********| | | | |
411 . . . . . .
412 . . . . . .
413 | | | | | |
414 | | | | | |
415 | (F33) SIP | | | | |
416 | BYE | | | | |
417 |**********>| | | | |
418 | | (F34) SIP | | | |
419 | | BYE | | | |
420 | |***********>| | | |
421 | | (F35) SIP | | | |
422 | | 200 OK | | | |
423 | |<***********| | | |
424 | (F36) SIP | | | | |
425 | 200 OK | | | | |
426 |<**********| | | | |
428 The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the
429 following table. (Mappings for several aspects not mentioned here
430 are specified in [I-D.ietf-stox-im].)
432 Table 2: Message syntax mapping from SIP to XMPP
434 +--------------------------+-----------------------------+
435 | SIP Header or Contents | XMPP Element or Attribute |
436 +--------------------------+-----------------------------+
437 | Call-ID | |
438 | transaction identifier | id |
439 +--------------------------+-----------------------------+
441 The protocol flow begins when Romeo starts a chat session with
442 Juliet.
444 Example 10: Romeo starts chat session (F19)
446 | INVITE sip:juliet@example.com SIP/2.0
447 | To:
448 | From:
449 | Contact: ;gr=orchard
450 | Subject: Open chat with Romeo?
451 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
452 | Content-Type: application/sdp
453 |
454 | c=IN IP4 s2x.example.net
455 | m=message 7313 TCP/MSRP *
456 | a=accept-types:text/plain
457 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
459 Upon receiving the INVITE, the SIP (MSRP) server needs to determine
460 the identity of the domain portion of the Request-URI or To header,
461 which it does by following the procedures explained in Section 5 of
462 [I-D.ietf-stox-core]. If the domain is an XMPP domain, the SIP
463 server will hand off the INVITE to an associated SIP-XMPP gateway or
464 connection manager that natively communicates with XMPP servers.
466 Example 11: Gateway accepts session on Juliet's behalf (F21)
468 | SIP/2.0 200 OK
469 | To: ;gr=orchard
470 | From:
471 | Contact: ;gr=balcony
472 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
473 | Content-Type: application/sdp
474 |
475 | c=IN IP4 x2s.example.com
476 | m=message 8763 TCP/MSRP *
477 | a=accept-types:text/plain
478 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
480 Example 12: Romeo sends ACK (F23)
482 | ACK sip:juliet@example.com SIP/2.0
483 | To: ;gr=balcony
484 | From:
485 | Contact: ;gr=orchard
486 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
488 Example 13: Romeo sends message (F24)
490 | MSRP ad49kswow SEND
491 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
492 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
493 | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E
494 | Byte-Range: 1-32/32
495 | Failure-Report: no
496 | Content-Type: text/plain
497 |
498 | I take thee at thy word ...
499 | -------ad49kswow$
501 Example 14: SIP-XMPP gateway maps MSRP message to XMPP (F27)
503 |
507 | F6989A8C-DE8A-4E21-8E07-F0898304796F
508 | I take thee at thy word ...
509 |
510 Example 15: Juliet sends reply (F29)
512 |
516 | 29377446-0CBB-4296-8958-590D79094C50
517 | What man art thou ...?
518 |
520 Example 16: Gateway maps XMPP message to MSRP (F31)
522 | MSRP ms53b7z9 SEND
523 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
524 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
525 | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41
526 | Byte-Range: 1-25/25
527 | Failure-Report: no
528 | Content-Type: text/plain
529 |
530 | What man art thou ...?
531 | -------ms53b7z9$
533 Example 17: Romeo terminates chat session (F33)
535 | BYE juliet@example.com sip: SIP/2.0
536 | To: ;gr=balcony
537 | From:
538 | Contact: ;gr=orchard
539 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
540 | Cseq: 1 BYE
541 | Content-Length: 0
543 Example 18: Gateway acknowledges termination of session on behalf of
544 Juliet (F35)
546 | SIP/2.0 200 OK
547 | To: ;gr=balcony
548 | From:
549 | Contact: ;gr=orchard
550 | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F
551 | CSeq: 1 BYE
553 6. Composing Events
555 Both XMPP and MSRP enable a client to receive notifications when a
556 person's conversation partner is composing an instant message within
557 the context of a chat session.
559 For XMPP, the Chat State Notifications specification [XEP-0085]
560 defines five states: active, inactive, gone, composing, and paused.
561 Some of these states are related to the act of message composition
562 (composing, paused), whereas others are related to the sender's
563 involvement with the chat session (active, inactive, gone).
565 For MSRP (and SIP/SIMPLE in general), the Indication of Message
566 Composition for Instant Messaging specification [RFC3994] defines two
567 states: idle and active. Here the idle state indicates that the
568 sender is not actively composing a message, and the active state
569 indicates that the sender is indeed actively composing a message (the
570 sending client simply toggles between the two states, changing to
571 active if the user is actively composing a message and changing to
572 idle if the user is no longer actively composing a message).
574 Because the XEP-0085 states can represent information that is not
575 captured in RFC 3994, gateways can either (a) map only the composing-
576 related states or (b) map all the XEP-0085 states.
578 The following mappings are suggested.
580 Table 3: Mapping of SIP/SIMPLE isComposing events to XMPP chat states
582 +-------------------+--------------------+
583 | isComposing Event | Chat State |
584 +-------------------+--------------------+
585 | active | composing |
586 | idle | active |
587 +-------------------+--------------------+
589 Table 4: Mapping of XMPP chat states to SIP/SIMPLE isComposing events
591 +-------------------+--------------------+
592 | Chat State | isComposing Event |
593 +-------------------+--------------------+
594 | active | idle |
595 | inactive | idle |
596 | gone | [none, see note] |
597 | composing | active |
598 | paused | idle |
599 +-------------------+--------------------+
601 Although there is no direct mapping for the "gone" chat state (which
602 is not to be confused with the stanza error condition defined
603 in [RFC6120]) to an isComposing event, receipt of the "gone" state
604 can be used as a trigger for terminating the formal chat session
605 within MSRP, i.e., for sending a SIP BYE for the session from the
606 XMPP-SIP gateway to the SIP user. The following examples illustrate
607 this indirect mapping.
609 Example 19: Juliet sends gone chat state
611 |
615 | 29377446-0CBB-4296-8958-590D79094C50
616 |
617 |
619 Example 20: XMPP-SIP 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: 1 BYE
626 | Content-Length: 0
628 7. Delivery Reports
630 Both XMPP and MSRP enable a client to receive notifications when a
631 message has been received by the intended recipient.
633 For XMPP, the Message Receipts specification [XEP-0184] defines a
634 method and XML namespace for requesting and returning indications
635 that a message has been received by a client controlled by the
636 intended recipient.
638 For MSRP, a native reporting feature is included, in the form of
639 REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
641 Examples follow.
643 First, the XMPP user sends a message containing a request for
644 delivery notification.
646 Example 21: Juliet sends XMPP message with receipt request
648 |
652 | 29377446-0CBB-4296-8958-590D79094C50
653 | What man art thou ...?
654 |
655 |
657 Example 22: Gateway maps XMPP message to MSRP
659 | MSRP bf9m36d5 SEND
660 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
661 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
662 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
663 | Byte-Range: 1-25/25
664 | Success-Report: yes
665 | Failure-Report: no
666 | Content-Type: text/plain
667 |
668 | What man art thou ...?
669 | -------bf9m36d5$
671 Next, the recipient returns a report.
673 Example 23: Romeo returns MSRP receipt
675 | MSRP hx74g336 REPORT
676 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
677 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
678 | Message-ID: 6187CF9B-317A-41DA-BB6A-5E48A9C794EF
679 | Byte-Range: 1-106/106
680 | Status: 000 200 OK
681 | -------hx74g336$
683 Example 24: SIP-XMPP gateway maps receipt to XMPP
685 |
688 |
689 |
691 8. Internationalization Considerations
693 Relevant discussion of internationalized text in messages can be
694 found in [I-D.ietf-stox-im].
696 9. IANA Considerations
698 This document requests no actions of IANA.
700 10. Security Considerations
702 Detailed security considerations for instant messaging protocols are
703 given in [RFC2779], for MSRP chat in [RFC4975] (see also [RFC3261]
704 when SIP is used to negotiate MSRP sessions), and for XMPP-based
705 instant messaging in [RFC6121] (see also [RFC6120]). The security
706 considerations provided in [I-D.ietf-stox-core] also apply.
708 This document specifies methods for exchanging instant messages
709 through a gateway that translates between SIP/MSRP and XMPP. Such a
710 gateway MUST be compliant with the minimum security requirements of
711 the textual chat protocols for which it translates (i.e., MSRP and
712 XMPP). The addition of gateways to the security model of instant
713 messaging specified in [RFC2779] introduces some new risks. In
714 particular, end-to-end security properties (especially
715 confidentiality and integrity) between instant messaging clients that
716 interface through an MSRP-XMPP gateway can be provided only if common
717 formats are supported. Specification of those common formats is out
718 of scope for this document, although it is suggested to use [RFC3862]
719 for instant messages.
721 11. References
723 11.1. Normative References
725 [I-D.ietf-stox-core]
726 Saint-Andre, P., Houri, A., and J. Hildebrand,
727 "Interworking between the Session Initiation Protocol
728 (SIP) and the Extensible Messaging and Presence Protocol
729 (XMPP): Core", draft-ietf-stox-core-11 (work in progress),
730 February 2014.
732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
733 Requirement Levels", BCP 14, RFC 2119, March 1997.
735 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
736 A., Peterson, J., Sparks, R., Handley, M., and E.
737 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
738 June 2002.
740 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
741 Messaging (CPIM): Message Format", RFC 3862, August 2004.
743 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
744 Instant Messaging", RFC 3994, January 2005.
746 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
747 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
749 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
750 Protocol (XMPP): Core", RFC 6120, March 2011.
752 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
753 Protocol (XMPP): Instant Messaging and Presence", RFC
754 6121, March 2011.
756 [XEP-0085]
757 Saint-Andre, P. and D. Smith, "Chat State Notifications",
758 XSF XEP 0085, September 2009.
760 [XEP-0184]
761 Saint-Andre, P. and J. Hildebrand, "Message Delivery
762 Receipts", XSF XEP 0184, March 2011.
764 11.2. Informative References
766 [I-D.ietf-stox-im]
767 Saint-Andre, P., Houri, A., and J. Hildebrand,
768 "Interworking between the Session Initiation Protocol
769 (SIP) and the Extensible Messaging and Presence Protocol
770 (XMPP): Instant Messaging", draft-ietf-stox-im-08 (work in
771 progress), March 2014.
773 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
774 / Presence Protocol Requirements", RFC 2779, February
775 2000.
777 Appendix A. Acknowledgements
779 Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an
780 early version of this document.
782 Thanks to Mary Barnes, Dave Crocker, Adrian Georgescu, Philipp
783 Hancke, Saul Ibarra Corretge, and Tory Patnoe for their feedback.
785 The authors gratefully acknowledge the assistance of Markus Isomaki
786 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
787 and Alissa Cooper as the sponsoring Area Directors.
789 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
790 employing him during his work on earlier versions of this document.
792 Authors' Addresses
794 Peter Saint-Andre
795 &yet
796 P.O. Box 787
797 Parker, CO 80134
798 USA
800 Email: ietf@stpeter.im
802 Salvatore Loreto
803 Ericsson
804 Hirsalantie 11
805 Jorvas 02420
806 Finland
808 Email: Salvatore.Loreto@ericsson.com