-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-saintandre-sip-xmpp-chat.xml
645 lines (613 loc) · 29.8 KB
/
draft-saintandre-sip-xmpp-chat.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="1"?>
<rfc category="std" docName="draft-saintandre-sip-xmpp-chat-06" ipr="trust200902">
<front>
<title abbrev="SIP-XMPP Interworking: Chat">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="E." surname="Gavita" fullname="Eddy Gavita">
<organization>Ericsson</organization>
<address>
<postal>
<street>Decarie Boulevard</street>
<code></code>
<city>Town of Mount Royal</city>
<region>Quebec</region>
<country>Canada</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="N." surname="Hossain" fullname="Nazin Hossain">
<organization>Ericsson</organization>
<address>
<postal>
<street>Decarie Boulevard</street>
<city>Town of Mount Royal</city>
<region>Quebec</region>
<country>Canada</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>RAI</area>
<keyword>Text Chat</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Session Initiation Protocol</keyword>
<keyword>SIP</keyword>
<keyword>Message Sessions Relay Protocol</keyword>
<keyword>MSRP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>Both the Session Initiation Protocol <xref target="RFC3261"/> and the Extensible Messaging and Presence Protocol <xref target='RFC6120'/> can be used for the purpose of one-to-one text chat over the Internet. To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.</t>
<t>The architectural assumptions underlying such protocol mappings are provided in <xref target='I-D.saintandre-sip-xmpp-core'/>, including mapping of addresses and error conditions. This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP messages of type "chat" and the Message Session Relay Protocol <xref target='RFC4975'/>. Mappings for single instant messages and groupchat are provided in separate documents.</t>
<t>The approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:</t>
<t>
<list style='symbols'>
<t>XMPP chat sessions using message stanzas of type "chat" are specified in <xref target="RFC6121"/>.</t>
<t>SIP-based chat sessions using the SIP INVITE and SEND request types are specified in <xref target='RFC4975'/>.</t>
</list>
</t>
<t>In SIMPLE, a chat session is formally negotiated just as any other session type is using SIP. By contrast, a one-to-one chat "session" in XMPP is an informal construct and is not formally negotiated: a user simply sends a message of type "chat" to a contact, the contact then replies to the message, and the sum total of such messages exchanged during a defined period of time is considered to be a chat session. To overcome the disparity between these approaches, a gateway that wishes to map between SIP and XMPP for one-to-one chat sessions needs to maintain some additional state, as described below.</t>
<t>The discussion venue for this document is the mailing list of the DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for subscription information and discussion archives.</t>
</section>
<section title="Terminology" anchor="terms">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
</section>
<section title="XMPP to MSRP" anchor="xmpp2msrp">
<t>In XMPP, the "informal session" approach is to simply send someone a <message/> of type "chat" without starting any session negotiation ahead of time (as described in <xref target="RFC6121"/>). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in <xref target="I-D.saintandre-sip-xmpp-core"/>. However, the XMPP informal session approach can also be mapped to MSRP if the XMPP-to-SIP gateway maintains additional state.</t>
<t>The order of events is as follows.</t>
<figure>
<artwork><![CDATA[
XMPP User GW SIP User
| | |
|(F1) (XMPP) Chat message | |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| |(F5) (MSRP) SEND |
| |------------------------->|
| |(F6) (MSRP) A reply |
| |<-------------------------|
|(F7) (XMPP) A reply | |
|<-------------------------| |
| | |
. . .
. . .
. . .
| | |
| |(F8) (SIP) BYE |
| |<-------------------------|
| |(F9) (SIP) 200 OK |
| |------------------------->|
| | |
]]></artwork>
</figure>
<t>First the XMPP user would generate an XMPP chat message.</t>
<figure>
<preamble>Example: (F1) Juliet sends an XMPP message</preamble>
<artwork><![CDATA[
<message from='[email protected]/balcony'
to='[email protected]'
type='chat'>
<thread>711609sa</thread>
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></artwork>
</figure>
<t>The local SIP-to-XMPP gateway at the SIMPLE server would then determine if Romeo supports MSRP. If so, the SIP-to-XMPP gateway would initiate an MSRP session with Romeo on Juliet's behalf.</t>
<figure>
<preamble>Example: (F2) Gateway starts a formal session on behalf of Juliet</preamble>
<artwork><![CDATA[
INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=balcony
Subject: Open chat with Juliet?
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 x2s.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
]]></artwork>
</figure>
<t>Here we assume that Romeo accepts the MSRP session request.</t>
<figure>
<preamble>Example: (F3) Romeo accepts the request</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:[email protected]>;gr=balcony
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=orchard
Call-ID: 711609sa
Content-Type: application/sdp
c=IN IP4 s2x.example.net
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
]]></artwork>
</figure>
<t>The XMPP-to-SIP gateway then acknowledges the session acceptance on behalf of Romeo.</t>
<figure>
<preamble>Example: (F4) Gateway sends ACK to Romeo's UA</preamble>
<artwork><![CDATA[
ACK sip:[email protected] SIP/2.0
To: <sip:[email protected]>;gr=orchard
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=balcony
Call-ID: 711609sa
]]></artwork>
</figure>
<t>The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP.</t>
<figure>
<preamble>Example: (F5) Gateway transforms XMPP message to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
Art thou not Romeo, and a Montague?
-------a786hjs2$
]]></artwork>
</figure>
<t>Romeo can then send a reply using his MSRP user agent.</t>
<figure>
<preamble>Example: (F6) Romeo sends a reply</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Failure-Report: no
Content-Type: text/plain
Neither, fair saint, if either thee dislike.
-------a786hjs2$
]]></artwork>
</figure>
<t>The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.</t>
<figure>
<preamble>Example: (F7) Gateway transforms MSRP message to XMPP</preamble>
<artwork><![CDATA[
<message from='[email protected]/orchard'
to='[email protected]/balcony'
type='chat'>
<thread>711609sa</thread>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
]]></artwork>
</figure>
<t>When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE.</t>
<figure>
<preamble>Example: (F8) Romeo terminates the chat session</preamble>
<artwork><![CDATA[
BYE [email protected] sip: SIP/2.0
Max-Forwards: 70
From: <sip:[email protected]>;tag=087js
To: <sip:[email protected]>;tag=786
Call-ID: 711609sa
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<t>The BYE is then acknowledged by the XMPP-to-SIP gateway.</t>
<figure>
<preamble>Example: (F9) Gateway acknowledges termination</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
From: <sip:[email protected]>;tag=786
To: <sip:[email protected]>;tag=087js
Call-ID: 711609sa
CSeq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
</section>
<section title="MSRP to XMPP" anchor="msrp2xmpp">
<t>When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows.</t>
<figure>
<artwork><![CDATA[
SIP User GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
|(F2)(SIP) 200 OK | |
|<------------------------| |
|(F3)(SIP) ACK | |
|------------------------>| |
|(F4)(MSRP) SEND | |
|------------------------>| |
| |(F5)(XMPP) A chat message |
| |------------------------->|
| |(F6)(XMPP) A reply |
| |<-------------------------|
| | |
|(F7)(MSRP) SEND | |
|<------------------------| |
| | |
. . .
. . .
. . .
| | |
|(F8)(SIP) BYE | |
|------------------------>| |
|(F9)(SIP) 200 OK | |
|<------------------------| |
| | |
]]></artwork>
</figure>
<figure>
<preamble>Example: (F1) SIP user starts the session</preamble>
<artwork><![CDATA[
INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=orchard
Subject: Open chat with Romeo?
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 s2x.example.net
m=message 7313 TCP/MSRP *
a=accept-types:text/plain
a=lang:en
a=lang:it
a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
]]></artwork>
</figure>
<figure>
<preamble>Example: (F2) Gateway accepts session on Juliet's behalf</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:[email protected]>;gr=orchard
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=balcony
Call-ID: 742507no
Content-Type: application/sdp
c=IN IP4 x2s.example.com
m=message 8763 TCP/MSRP *
a=accept-types:text/plain
a=lang:it
a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
]]></artwork>
</figure>
<figure>
<preamble>Example: (F3) Romeo sends ACK</preamble>
<artwork><![CDATA[
ACK sip:[email protected] SIP/2.0
To: <sip:[email protected]>;gr=balcony
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=orchard
Call-ID: 742507no
]]></artwork>
</figure>
<figure>
<preamble>Example: (F4) Romeo sends a message</preamble>
<artwork><![CDATA[
MSRP ad49kswow SEND
To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp
Message-ID: 44921zaqwsx
Byte-Range: 1-32/32
Failure-Report: no
Content-Type: text/plain
I take thee at thy word ...
-------ad49kswow$
]]></artwork>
</figure>
<figure>
<preamble>Example: (F5) Romeo sends a message (XMPP translation)</preamble>
<artwork><![CDATA[
<message from='[email protected]'
to='[email protected]'
type='chat'>
<thread>742507no</thread>
<body>I take thee at thy word ...</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>Example: (F6) Juliet sends a reply</preamble>
<artwork><![CDATA[
<message from='[email protected]'
to='[email protected]'
type='chat'>
<thread>711609sa</thread>
<body>What man art thou ...?</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>Example: (F8) Gateway transforms XMPP message to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp
From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Failure-Report: no
Content-Type: text/plain
What man art thou ...?
-------a786hjs2$
]]></artwork>
</figure>
<figure>
<preamble>Example: (F9) Romeo terminates the session</preamble>
<artwork><![CDATA[
BYE [email protected] sip: SIP/2.0
Max-Forwards: 70
To: <sip:[email protected]>;gr=balcony
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=orchard
Call-ID: 742507no
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<figure>
<preamble>Example: (F10) Gateway acknowledges the termination of the session on behalf of XMPP user</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:[email protected]>;gr=balcony
From: <sip:[email protected]>
Contact: <sip:[email protected]>;gr=orchard
Call-ID: 742507no
CSeq: 1 BYE
]]></artwork>
</figure>
</section>
<section title="Security Considerations" anchor="security">
<t>Detailed security considerations for instant messaging protocols are given in <xref target='RFC2779'/>, for SIP-based instant messaging in <xref target="RFC3428"/> (see also <xref target="RFC3261"/>), and for XMPP-based instant messaging in <xref target="RFC6121"/> (see also <xref target="RFC6120"/>).</t>
<t>This document specifies methods for exchanging instant messages through a gateway that translates between SIP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the instant messaging protocols for which it translates (i.e., SIP and XMPP). The addition of gateways to the security model of instant messaging specified in <xref target="RFC2779"/> introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between instant messaging user agents that interface through a SIMPLE-XMPP gateway can be provided only if common formats are supported. Specification of those common formats is out of scope for this document, although it is recommended to use <xref target="RFC3862"/> for instant messages.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no actions of IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='I-D.saintandre-sip-xmpp-core'>
<front>
<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='A' surname='Houri' fullname='Avshalom Houri'>
<organization />
</author>
<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
<organization />
</author>
<date month='June' day='13' year='2013' />
<abstract><t>As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-sip-xmpp-core-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-05.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>[email protected]</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date year='2002' month='June' />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>
<reference anchor="RFC3862">
<front>
<title>Common Presence and Instant Messaging (CPIM): Message Format</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'>
<organization /></author>
<author initials='D.' surname='Atkins' fullname='D. Atkins'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3862' />
<format type='TXT' octets='56133' target='ftp://ftp.isi.edu/in-notes/rfc3862.txt' />
</reference>
<reference anchor='RFC4975'>
<front>
<title>The Message Session Relay Protocol (MSRP)</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'>
<organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4975' />
<format type='TXT' octets='144254' target='ftp://ftp.isi.edu/in-notes/rfc4975.txt' />
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor='RFC6121'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6121' />
<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC2779">
<front>
<title abbrev='Instant Messaging/Presence Protocol'>Instant Messaging / Presence Protocol Requirements</title>
<author initials='M.' surname='Day' fullname='Mark Day'>
<organization>SightPath, Inc.</organization>
<address>
<postal>
<street>135 Beaver Street</street>
<city>Waltham</city>
<region>MA</region>
<code>02452</code>
<country>US</country></postal>
<email>[email protected]</email></address></author>
<author initials='S.' surname='Aggarwal' fullname='Sonu Aggarwal'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>[email protected]</email></address></author>
<author initials='J.' surname='Vincent' fullname='Jesse Vincent'>
<organization>Into Networks, Inc.</organization>
<address>
<postal>
<street>150 Cambridgepark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country></postal>
<email>[email protected]</email></address></author>
<date month='February' year='2000' />
<abstract>
<t>Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.</t>
<t>Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.</t></abstract></front>
<seriesInfo name='RFC' value='2779' />
<format type='TXT' octets='47420' target='ftp://ftp.isi.edu/in-notes/rfc2779.txt' />
</reference>
<reference anchor='RFC3428'>
<front>
<title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='C.' surname='Huitema' fullname='C. Huitema'>
<organization /></author>
<author initials='D.' surname='Gurle' fullname='D. Gurle'>
<organization /></author>
<date year='2002' month='December' />
<abstract>
<t>Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='3428' />
<format type='TXT' octets='41475' target='ftp://ftp.isi.edu/in-notes/rfc3428.txt' />
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Some text in this document was borrowed from <xref target='I-D.saintandre-sip-xmpp-core'/>.</t>
<t>Thanks to Adrian Georgescu, Saul Ibarra, and Tory Patnoe for their feedback.</t>
</section>
</back>
</rfc>