idnits 2.17.1
draft-ietf-stox-chat-01.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 (September 18, 2013) is 3871 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 (-11) exists of
draft-ietf-stox-core-04
-- 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 Cisco Systems, Inc.
4 Intended status: Standards Track S. Loreto
5 Expires: March 22, 2014 E. Gavita
6 N. Hossain
7 Ericsson
8 September 18, 2013
10 Interworking between the Session Initiation Protocol (SIP) and the
11 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat
12 draft-ietf-stox-chat-01
14 Abstract
16 This document defines a bidirectional protocol mapping for the
17 exchange of instant messages in the context of a one-to-one chat
18 session between a user of the Session Initiation Protocol (SIP) and a
19 user of the Extensible Messaging and Presence Protocol (XMPP).
20 Specifically for SIP text chat, this document specifies a mapping to
21 the Message Session Relay Protocol (MSRP).
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on March 22, 2014.
40 Copyright Notice
42 Copyright (c) 2013 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. XMPP to MSRP . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 4. MSRP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 7
61 5. Composing Events . . . . . . . . . . . . . . . . . . . . . . . 10
62 6. Delivery Reports . . . . . . . . . . . . . . . . . . . . . . . 12
63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
67 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
71 1. Introduction
73 Both the Session Initiation Protocol [RFC3261] and the Extensible
74 Messaging and Presence Protocol [RFC6120] can be used for the purpose
75 of one-to-one text chat over the Internet. To ensure interworking
76 between these technologies, it is important to define bidirectional
77 protocol mappings.
79 The architectural assumptions underlying such protocol mappings are
80 provided in [I-D.ietf-stox-core], including mapping of addresses and
81 error conditions. This document specifies mappings for one-to-one
82 text 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 [RFC4975].
85 Mappings for single instant messages and groupchat are provided in
86 separate documents.
88 The approach taken here is to directly map syntax and semantics from
89 one protocol to another. The mapping described herein depends on the
90 protocols defined in the following specifications:
92 o XMPP chat sessions using message stanzas of type "chat" are
93 specified in [RFC6121].
94 o SIP-based chat sessions using the SIP INVITE and SEND request
95 types are specified in [RFC4975].
97 In SIMPLE, a chat session is formally negotiated just as any other
98 session type is using SIP. By contrast, a one-to-one chat "session"
99 in XMPP is an informal construct and is not formally negotiated: a
100 user simply sends a message of type "chat" to a contact, the contact
101 then replies to the message, and the sum total of such messages
102 exchanged during a defined period of time is considered to be a chat
103 session. To overcome the disparity between these approaches, a
104 gateway that wishes to map between SIP and XMPP for one-to-one chat
105 sessions needs to maintain some additional state, as described below.
107 The discussion venue for this document is the mailing list of the
108 STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for
109 subscription information and discussion archives.
111 2. Terminology
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
115 "OPTIONAL" in this document are to be interpreted as described in
116 [RFC2119].
118 3. XMPP to MSRP
120 In XMPP, the "informal session" approach is to simply send someone a
121 of type "chat" without starting any session negotiation
122 ahead of time (as described in [RFC6121]). The XMPP "informal
123 session" approach maps very well into a SIP MESSAGE request, as
124 described in [I-D.ietf-stox-core]. However, the XMPP informal
125 session approach can also be mapped to MSRP if the XMPP-to-SIP
126 gateway maintains additional state.
128 The order of events is as follows.
130 XMPP User GW SIP User
131 | | |
132 |(F1) (XMPP) Chat message | |
133 |------------------------->| |
134 | |(F2) (SIP) INVITE |
135 | |------------------------->|
136 | |(F3) (SIP) 200 OK |
137 | |<-------------------------|
138 | |(F4) (SIP) ACK |
139 | |------------------------->|
140 | |(F5) (MSRP) SEND |
141 | |------------------------->|
142 | |(F6) (MSRP) A reply |
143 | |<-------------------------|
144 |(F7) (XMPP) A reply | |
145 |<-------------------------| |
146 | | |
147 . . .
148 . . .
149 . . .
150 | | |
151 | |(F8) (SIP) BYE |
152 | |<-------------------------|
153 | |(F9) (SIP) 200 OK |
154 | |------------------------->|
155 | | |
157 First the XMPP user would generate an XMPP chat message.
159 Example: (F1) Juliet sends an XMPP message
161 |
164 | 711609sa
165 | Art thou not Romeo, and a Montague?
166 |
168 The local SIP-to-XMPP gateway at the SIMPLE server would then
169 initiate an MSRP session with Romeo on Juliet's behalf (since there
170 is no reliable way for the SIMPLE server to determine if Romeo's user
171 agent supports MSRP, it simply needs to guess).
173 Example: (F2) Gateway starts a formal session on behalf of Juliet
175 | INVITE sip:romeo@example.net SIP/2.0
176 | To:
177 | From:
178 | Contact: ;gr=balcony
179 | Subject: Open chat with Juliet?
180 | Call-ID: 711609sa
181 | Content-Type: application/sdp
182 |
183 | c=IN IP4 x2s.example.com
184 | m=message 7654 TCP/MSRP *
185 | a=accept-types:text/plain
186 | a=lang:en
187 | a=lang:it
188 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
190 Here we assume that Romeo accepts the MSRP session request.
192 Example: (F3) Romeo accepts the request
194 | SIP/2.0 200 OK
195 | To: ;gr=balcony
196 | From:
197 | Contact: ;gr=orchard
198 | Call-ID: 711609sa
199 | Content-Type: application/sdp
200 |
201 | c=IN IP4 s2x.example.net
202 | m=message 12763 TCP/MSRP *
203 | a=accept-types:text/plain
204 | a=lang:it
205 | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
206 The XMPP-to-SIP gateway then acknowledges the session acceptance on
207 behalf of Romeo.
209 Example: (F4) Gateway sends ACK to Romeo's UA
211 | ACK sip:juliet@example.com SIP/2.0
212 | To: ;gr=orchard
213 | From:
214 | Contact: ;gr=balcony
215 | Call-ID: 711609sa
217 The XMPP-to-SIP gateway then transforms the original XMPP chat
218 message into MSRP.
220 Example: (F5) Gateway transforms XMPP message to MSRP
222 | MSRP a786hjs2 SEND
223 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
224 | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
225 | Message-ID: 87652491
226 | Byte-Range: 1-25/25
227 | Content-Type: text/plain
228 |
229 | Art thou not Romeo, and a Montague?
230 | -------a786hjs2$
232 Romeo can then send a reply using his MSRP user agent.
234 Example: (F6) Romeo sends a reply
236 | MSRP a786hjs2 SEND
237 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
238 | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
239 | Message-ID: 87652491
240 | Byte-Range: 1-25/25
241 | Failure-Report: no
242 | Content-Type: text/plain
243 |
244 | Neither, fair saint, if either thee dislike.
245 | -------a786hjs2$
247 The SIP-to-XMPP gateway would then transform that message into
248 appropriate XMPP syntax for routing to the intended recipient.
250 Example: (F7) Gateway transforms MSRP message to XMPP
252 |
255 | 711609sa
256 | Neither, fair saint, if either thee dislike.
257 |
259 When the MSRP user wishes to end the chat session, the user's MSRP
260 client sends a SIP BYE.
262 Example: (F8) Romeo terminates the chat session
264 | BYE juliet@example.com sip: SIP/2.0
265 | Max-Forwards: 70
266 | From: ;tag=087js
267 | To: ;tag=786
268 | Call-ID: 711609sa
269 | Cseq: 1 BYE
270 | Content-Length: 0
272 The BYE is then acknowledged by the XMPP-to-SIP gateway.
274 Example: (F9) Gateway acknowledges termination
276 | SIP/2.0 200 OK
277 | From: ;tag=786
278 | To: ;tag=087js
279 | Call-ID: 711609sa
280 | CSeq: 1 BYE
281 | Content-Length: 0
283 4. MSRP to XMPP
285 When an MSRP client sends messages through a gateway to an XMPP
286 client that does not support formal sessinos, the order of events is
287 as follows.
289 SIP User GW XMPP User
290 | | |
291 |(F1)(SIP) INVITE | |
292 |------------------------>| |
293 |(F2)(SIP) 200 OK | |
294 |<------------------------| |
295 |(F3)(SIP) ACK | |
296 |------------------------>| |
297 |(F4)(MSRP) SEND | |
298 |------------------------>| |
299 | |(F5)(XMPP) A chat message |
300 | |------------------------->|
301 | |(F6)(XMPP) A reply |
302 | |<-------------------------|
303 | | |
304 |(F7)(MSRP) SEND | |
305 |<------------------------| |
306 | | |
307 . . .
308 . . .
309 . . .
310 | | |
311 |(F8)(SIP) BYE | |
312 |------------------------>| |
313 |(F9)(SIP) 200 OK | |
314 |<------------------------| |
315 | | |
317 Example: (F1) SIP user starts the session
319 | INVITE sip:juliet@example.com SIP/2.0
320 | To:
321 | From:
322 | Contact: ;gr=orchard
323 | Subject: Open chat with Romeo?
324 | Call-ID: 742507no
325 | Content-Type: application/sdp
326 |
327 | c=IN IP4 s2x.example.net
328 | m=message 7313 TCP/MSRP *
329 | a=accept-types:text/plain
330 | a=lang:en
331 | a=lang:it
332 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
333 Example: (F2) Gateway accepts session on Juliet's behalf
335 | SIP/2.0 200 OK
336 | To: ;gr=orchard
337 | From:
338 | Contact: ;gr=balcony
339 | Call-ID: 742507no
340 | Content-Type: application/sdp
341 |
342 | c=IN IP4 x2s.example.com
343 | m=message 8763 TCP/MSRP *
344 | a=accept-types:text/plain
345 | a=lang:it
346 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
348 Example: (F3) Romeo sends ACK
350 | ACK sip:juliet@example.com SIP/2.0
351 | To: ;gr=balcony
352 | From:
353 | Contact: ;gr=orchard
354 | Call-ID: 742507no
356 Example: (F4) Romeo sends a message
358 | MSRP ad49kswow SEND
359 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
360 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
361 | Message-ID: 44921zaqwsx
362 | Byte-Range: 1-32/32
363 | Failure-Report: no
364 | Content-Type: text/plain
365 |
366 | I take thee at thy word ...
367 | -------ad49kswow$
369 Example: (F5) Romeo sends a message (XMPP translation)
371 |
374 | 742507no
375 | I take thee at thy word ...
376 |
377 Example: (F6) Juliet sends a reply
379 |
382 | 711609sa
383 | What man art thou ...?
384 |
386 Example: (F8) Gateway transforms XMPP message to MSRP
388 | MSRP a786hjs2 SEND
389 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
390 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
391 | Message-ID: 87652491
392 | Byte-Range: 1-25/25
393 | Failure-Report: no
394 | Content-Type: text/plain
395 |
396 | What man art thou ...?
397 | -------a786hjs2$
399 Example: (F9) Romeo terminates the session
401 | BYE juliet@example.com sip: SIP/2.0
402 | Max-Forwards: 70
403 | To: ;gr=balcony
404 | From:
405 | Contact: ;gr=orchard
406 | Call-ID: 742507no
407 | Cseq: 1 BYE
408 | Content-Length: 0
410 Example: (F10) Gateway acknowledges the termination of the session on
411 behalf of XMPP user
413 | SIP/2.0 200 OK
414 | To: ;gr=balcony
415 | From:
416 | Contact: ;gr=orchard
417 | Call-ID: 742507no
418 | CSeq: 1 BYE
420 5. Composing Events
422 Both XMPP and MSRP enable a user agent to receive notifications when
423 a person's conversation partner is composing an instant message
424 within the context of a chat session.
426 For XMPP, the Chat State Notifications specification [XEP-0085]
427 defines five states: active, inactive, gone, composing, and paused.
428 Some of these states are related to the act of message composition
429 (composing, paused), whereas others are related to the sender's
430 involvement with the chat session (active, inactive, gone).
432 For MSRP (and SIMPLE in general), the Indication of Message
433 Composition for Instant Messaging specification [RFC3994] defines two
434 states: idle and active. Here the idle state indicates that the
435 sender is not actively composing a message, and the active state
436 indicates that the sender is indeed actively composing a message (the
437 sending user agent simply toggles between the two states, changing to
438 active if the user is actively composing a message and changing to
439 idle if the user is no longer actively composing a message).
441 Because the XEP-0085 states can represent information that is not
442 captured in RFC 3994, gateways can either (a) map only the composing-
443 related states or (b) map all the XEP-0085 states.
445 The following mappings are suggested.
447 Table 1: Mapping of SIMPLE isComposing events to XMPP chat states
449 +-------------------+--------------------+
450 | isComposing Event | Chat State |
451 +-------------------+--------------------+
452 | active | composing |
453 | idle | active |
454 +-------------------+--------------------+
456 Table 2: Mapping of XMPP chat states to SIMPLE isComposing events
458 +-------------------+--------------------+
459 | Chat State | isComposing Event |
460 +-------------------+--------------------+
461 | active | idle |
462 | inactive | idle |
463 | gone | [none, see note] |
464 | composing | active |
465 | paused | idle |
466 +-------------------+--------------------+
468 Note: Although there is no mapping for the "gone" chat state, receipt
469 of the "gone" state can be used as a trigger for terminating the
470 formal chat session within MSRP.
472 6. Delivery Reports
474 Both XMPP and MSRP enable a user agent to receive notifications when
475 a message has been received by the intended recipient.
477 For XMPP, the Message Receipts specification [XEP-0184] defines a
478 method and XML namespace for requesting and returning indications
479 that a message has been received by a client controlled by the
480 intended recipient.
482 For MSRP, a native reporting feature is included, in the form of
483 report chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]).
485 Examples follow.
487 First, the XMPP user sends a message containing a request for
488 delivery notification.
490 Example: Juliet sends a message with a receipt request
492 |
496 | 711609sa
497 | What man art thou ...?
498 |
499 |
501 Example: Gateway transforms XMPP message to MSRP
503 | MSRP a786hjs2 SEND
504 | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
505 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
506 | Message-ID: 87652491
507 | Byte-Range: 1-25/25
508 | Success-Report: yes
509 | Failure-Report: no
510 | Content-Type: text/plain
511 |
512 | What man art thou ...?
513 | -------a786hjs2$
515 Next, the recipient returns a report.
517 Example: Recipient returns receipt
519 | MSRP hx74g336 REPORT
520 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
521 | From-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
522 | Message-ID: 87652491
523 | Byte-Range: 1-106/106
524 | Status: 000 200 OK
525 | -------hx74g336$
527 Example: Transformed message receipt
529 |
532 |
533 |
535 7. IANA Considerations
537 This document requests no actions of IANA.
539 8. Security Considerations
541 Detailed security considerations for instant messaging protocols are
542 given in [RFC2779], for SIP-based instant messaging in [RFC3428] (see
543 also [RFC3261]), and for XMPP-based instant messaging in [RFC6121]
544 (see also [RFC6120]).
546 This document specifies methods for exchanging instant messages
547 through a gateway that translates between SIP and XMPP. Such a
548 gateway MUST be compliant with the minimum security requirements of
549 the instant messaging protocols for which it translates (i.e., SIP
550 and XMPP). The addition of gateways to the security model of instant
551 messaging specified in [RFC2779] introduces some new risks. In
552 particular, end-to-end security properties (especially
553 confidentiality and integrity) between instant messaging user agents
554 that interface through a SIMPLE-XMPP gateway can be provided only if
555 common formats are supported. Specification of those common formats
556 is out of scope for this document, although it is recommended to use
557 [RFC3862] for instant messages.
559 9. References
560 9.1. Normative References
562 [I-D.ietf-stox-core]
563 Saint-Andre, P., Houri, A., and J. Hildebrand,
564 "Interworking between the Session Initiation Protocol
565 (SIP) and the Extensible Messaging and Presence Protocol
566 (XMPP): Core", draft-ietf-stox-core-04 (work in progress),
567 July 2013.
569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
570 Requirement Levels", BCP 14, RFC 2119, March 1997.
572 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
573 A., Peterson, J., Sparks, R., Handley, M., and E.
574 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
575 June 2002.
577 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
578 Messaging (CPIM): Message Format", RFC 3862, August 2004.
580 [RFC3994] Schulzrinne, H., "Indication of Message Composition for
581 Instant Messaging", RFC 3994, January 2005.
583 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
584 Session Relay Protocol (MSRP)", RFC 4975, September 2007.
586 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
587 Protocol (XMPP): Core", RFC 6120, March 2011.
589 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
590 Protocol (XMPP): Instant Messaging and Presence",
591 RFC 6121, March 2011.
593 [XEP-0085]
594 Saint-Andre, P. and D. Smith, "Chat State Notifications",
595 XSF XEP 0085, September 2009.
597 [XEP-0184]
598 Saint-Andre, P. and J. Hildebrand, "Message Delivery
599 Receipts", XSF XEP 0184, March 2011.
601 9.2. Informative References
603 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
604 / Presence Protocol Requirements", RFC 2779,
605 February 2000.
607 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
608 and D. Gurle, "Session Initiation Protocol (SIP) Extension
609 for Instant Messaging", RFC 3428, December 2002.
611 Appendix A. Acknowledgements
613 Some text in this document was borrowed from [I-D.ietf-stox-core].
615 Thanks to Adrian Georgescu, Saul Ibarra, and Tory Patnoe for their
616 feedback.
618 Authors' Addresses
620 Peter Saint-Andre
621 Cisco Systems, Inc.
622 1899 Wynkoop Street, Suite 600
623 Denver, CO 80202
624 USA
626 Phone: +1-303-308-3282
627 Email: psaintan@cisco.com
629 Salvatore Loreto
630 Ericsson
631 Hirsalantie 11
632 Jorvas 02420
633 Finland
635 Email: Salvatore.Loreto@ericsson.com
637 Eddy Gavita
638 Ericsson
639 Decarie Boulevard
640 Town of Mount Royal, Quebec
641 Canada
643 Email: eddy.gavita@ericsson.com
644 Nazin Hossain
645 Ericsson
646 Decarie Boulevard
647 Town of Mount Royal, Quebec
648 Canada
650 Email: Nazin.Hossain@ericsson.com