-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-saintandre-sip-xmpp-im.xml
499 lines (466 loc) · 29.1 KB
/
draft-saintandre-sip-xmpp-im.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
<?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-im-03' ipr='trust200902'>
<front>
<title abbrev="SIP-XMPP Interworking: IM">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging</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="A." surname="Houri" fullname="Avshalom Houri">
<organization>IBM</organization>
<address>
<postal>
<street>Building 18/D, Kiryat Weizmann Science Park</street>
<city>Rehovot</city>
<code>76123</code>
<country>Israel</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<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>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>RAI</area>
<keyword>XMPP</keyword>
<keyword>Jabber</keyword>
<keyword>SIP</keyword>
<keyword>SIMPLE</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<abstract>
<t>This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>In order to help ensure interworking between instant messaging systems that conform to the instant messaging / presence requirements <xref target="RFC2779"/>, it is important to clearly define protocol mappings between such systems. Within the IETF, work has proceeded on two instant messaging technologies:</t>
<t>
<list style='symbols'>
<t>Various extensions to the Session Initiation Protocol (<xref target="RFC3261"/>) for instant messaging, as developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group; the relevant specification for instant messaging is <xref target='RFC3428'/></t>
<t>The Extensible Messaging and Presence Protocol (XMPP), which consists of a formalization of the core XML streaming protocols developed originally by the Jabber open-source community; the relevant specifications are <xref target='RFC6120'/> for the XML streaming layer and <xref target='RFC6121'/> for basic presence and instant messaging extensions</t>
</list>
</t>
<t>One approach to helping ensure interworking between these protocols is to map each protocol to the abstract semantics described in <xref target="RFC3860"/>; that is the approach taken by <xref target="I-D.ietf-simple-cpim-mapping"/> and <xref target="RFC3922"/>. By contrast, the approach taken in this document is to directly map semantics from one protocol to another (i.e., from SIP/SIMPLE to XMPP and vice-versa).</t>
<t>Both XMPP and IM-aware SIP systems enable entities to exchange "instant messages". The term "instant message" usually refers to messages sent between two entities for delivery in close to real time (rather than messages that are stored and forwarded to the intended recipient upon request). This document covers single messages only (sometimes called "pager-mode" messaging), since they form the lowest common denominator for instant messaging. One-to-one chat sessions and multi-party groupchat are covered in separate documents.</t>
<t>The architectural assumptions underlying such direct mappings are provided in <xref target='I-D.saintandre-sip-xmpp-core'/>, including mapping of addresses and error condisions. The mappings specified in this document cover basic instant messaging functionality, i.e., the exchange of a single instant message between a SIP user and an XMPP user in either direction. Mapping of more advanced functionality is out of scope for this document, but other documents in this "series" cover such topics.</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 SIP" anchor="xmpp2sip">
<t>As described in <xref target="RFC6121"/>, a single instant message is an XML <message/> stanza of type "normal" sent over an XML stream (since "normal" is the default for the 'type' attribute of the <message/> stanza, the attribute is often omitted). In this document we will assume that such a message is sent from an XMPP client to an XMPP server over an XML stream negotiated between the client and the server, and that the client is controlled by a human user (this is a simplifying assumption introduced for explanatory purposes only; the XMPP sender could be a bot-controlled client, a component such as a workflow application, a server, etc.). Continuing the tradition of Shakespeare examples in XMPP documentation, we will say that the XMPP user has an XMPP address of <[email protected]>.</t>
<t>When Juliet wants to send an instant message to Romeo, she interacts with her XMPP client, which generates an XMPP <message/> stanza. The syntax of the <message/> stanza, including required and optional elements and attributes, is defined in <xref target="RFC6121"/>. The following is an example of such a stanza:</t>
<figure>
<preamble>Example: XMPP user sends message:</preamble>
<artwork><![CDATA[
| <message from='[email protected]/balcony'
| to='[email protected]'>
| <body>Art thou not Romeo, and a Montague?</body>
| </message>
]]></artwork>
</figure>
<t>Upon receiving such a stanza, the XMPP server to which Juliet has connected either delivers it to a local recipient (if the hostname in the 'to' attribute matches one of the hostnames serviced by the XMPP server) or attempts to route it to the foreign domain that services the hostname in the 'to' attribute. Naturally, in this document we assume that the hostname in the 'to' attribute is an IM-aware SIP service hosted by a separate server. As specified in <xref target="RFC6121"/>, the XMPP server needs to determine the identity of the foreign domain, which it does by performing one or more DNS SRV lookups <xref target="RFC2782"/>. For message stanzas, the order of lookups recommended by <xref target="RFC6121"/> is to first try the "_xmpp-server" service as specified in <xref target="RFC6120"/> and to then try the "_im" service as specified in <xref target="RFC3861"/>. Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.example.net.", since we have already assumed that the example.net hostname is running a SIP instant messaging service. (Note: The XMPP server may have previously determined that the foreign domain is a SIMPLE server, in which case it would not need to perform the SRV lookups; the caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.)</t>
<t>Once the XMPP server has determined that the foreign domain is serviced by a SIMPLE server, it must determine how to proceed. We here assume that the XMPP server contains or has available to it an XMPP-SIMPLE gateway (such an architecture is described in <xref target='I-D.saintandre-sip-xmpp-core'/>). The XMPP server would then deliver the message stanza to the XMPP-SIMPLE gateway.</t>
<t>The XMPP-SIMPLE gateway is then responsible for translating the XMPP message stanza into a SIP MESSAGE request from the XMPP user to the SIP user:</t>
<figure>
<preamble>Example: XMPP user sends message (SIP transformation):</preamble>
<artwork><![CDATA[
| MESSAGE sip:[email protected] SIP/2.0
| Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
| Max-Forwards: 70
| To: sip:[email protected]
| From: sip:[email protected]
| Contact: sip:[email protected];gr=balcony
| Call-ID: [email protected]
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 35
|
| Art thou not Romeo, and a Montague?
]]></artwork>
</figure>
<t>The mapping of XMPP syntax elements to SIP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)</t>
<figure>
<preamble>Table 4: Message syntax mapping from XMPP to SIP</preamble>
<artwork><![CDATA[
+-----------------------------+--------------------------+
| XMPP Element or Attribute | SIP Header or Contents |
+-----------------------------+--------------------------+
| <body/> | body of MESSAGE |
| <subject/> | Subject |
| <thread/> | Call-ID |
| from | From |
| id | (no mapping) |
| to | To |
| type | (no mapping) |
| xml:lang | Content-Language |
+-----------------------------+--------------------------+
]]></artwork>
</figure>
</section>
<section title="SIP to XMPP" anchor="sip2xmpp">
<t>As described in <xref target="RFC3428"/>, a single instant message is a SIP MESSAGE request sent from a SIP user agent to an intended recipient who is most generally referenced by an Instant Message URI of the form <im:user@domain> but who may be referenced by a SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>. Here again we introduce the simplifying assumption that the user agent is controlled by a human user, whom we shall dub <[email protected]>.</t>
<t>When Romeo wants to send an instant message to Juliet, he interacts with his SIP user agent, which generates a SIP MESSAGE request. The syntax of the MESSAGE request is defined in <xref target="RFC3428"/>. The following is an example of such a request:</t>
<figure>
<preamble>Example: SIP user sends message:</preamble>
<artwork><![CDATA[
| MESSAGE sip:[email protected] SIP/2.0
| Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
| Max-Forwards: 70
| To: sip:[email protected];gr=balcony
| From: sip:[email protected]
| Contact: sip:[email protected];gr=orchard
| Call-ID: [email protected]
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 44
|
| Neither, fair saint, if either thee dislike.
]]></artwork>
</figure>
<t>Section 5 of <xref target="RFC3428"/> stipulates that a SIP User Agent presented with an im: URI should resolve it to a sip: or sips: URI. Therefore we assume that the Request-URI of a request received by a SIMPLE-XMPP gateway will contain a sip: or sips: URI. The gateway SHOULD resolve that address to an im: URI for SIP MESSAGE requests, then follow the rules in <xref target="RFC3861"/> regarding the "_im" SRV service for the target domain contained in the Request-URI. If SRV address resolution fails for the "_im" service, the gateway MUST either attempt a lookup for the "_xmpp-server" service as specified in <xref target="RFC6120"/> or return an error to the sender (the SIP "502 Bad Gateway" error seems most appropriate; see <xref target='I-D.saintandre-sip-xmpp-core'/> for details). If SRV address resolution succeeds, the gateway is responsible for translating the request into an XMPP message stanza from the SIP user to the XMPP user and returning a SIP "200 OK" message to the sender:</t>
<figure>
<preamble>Example: SIP user sends message (XMPP transformation):</preamble>
<artwork><![CDATA[
| <message from='[email protected]/orchard'
| to='[email protected]/balcony'>
| <body>Neither, fair saint, if either thee dislike.</body>
| </message>
]]></artwork>
</figure>
<t>The mapping of SIP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned in the foregoing table are undefined.)</t>
<figure>
<preamble>Table 5: Message syntax mapping from SIP to XMPP</preamble>
<artwork><![CDATA[
+--------------------------+-----------------------------+
| SIP Header or Contents | XMPP Element or Attribute |
+--------------------------+-----------------------------+
| Call-ID | <thread/> |
| Content-Language | xml:lang |
| CSeq | (no mapping) |
| From | from |
| Subject | <subject/> |
| Request-URI | to |
| body of MESSAGE | <body/> |
+--------------------------+-----------------------------+
]]></artwork>
</figure>
<t>Note: When transforming SIP pager-mode messages, a SIMPLE-XMPP gateway SHOULD specify no XMPP 'type' attribute or, equivalently, a 'type' attribute whose value is "normal".</t>
<t>Note: See <xref target='content'/> of this document about the handling of SIP message bodies that contain content types other than plain text.</t>
</section>
<section title='Content Types' anchor="content">
<t>SIP requests of type MESSAGE are allowed to contain essentially any content type. The recommended procedures for SIMPLE-to-XMPP gateways to use in handling these content types are as follows.</t>
<t>A SIMPLE-to-XMPP gateway MUST process SIP messages that contain message bodies of type "text/plain" and MUST encapsulate such message bodies as the XML character data of the XMPP <body/> element.</t>
<t>A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html"; if so, a gateway MUST transform the "text/html" content into XHTML content that conforms to the XHTML 1.0 Integration Set specified in <xref target='XEP-0071'/>.</t>
<t>Although a SIMPLE-to-XMPP gateway MAY process SIP messages that contain message bodies of types other than "text/plain" and "text/html", the handling of such content types is a matter of implementation.</t>
</section>
<section title='Security Considerations' anchor="sec">
<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 preferred 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='April' day='2' 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-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-04.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>
</address>
</author>
<date month='March' year='1997'></date>
<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' />
</reference>
<reference anchor='RFC2782'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>[email protected]</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<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>
<date month='February' year='2000' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='ftp://ftp.isi.edu/in-notes/rfc2782.txt' />
</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 month='June' year='2002' /></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='ftp://ftp.isi.edu/in-notes/rfc3261.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 month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3428' />
<format type='TXT' octets='41475' target='ftp://ftp.isi.edu/in-notes/rfc3428.txt' />
</reference>
<reference anchor="RFC3861">
<front>
<title>Address Resolution for Instant Messaging and Presence</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3861' />
<format type='TXT' octets='15764' target='ftp://ftp.isi.edu/in-notes/rfc3861.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>
<reference anchor="XEP-0071">
<front>
<title>XHTML-IM</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<date day="28" month="November" year="2012"/>
</front>
<seriesInfo name="XSF XEP" value="0071"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0071.html"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-simple-cpim-mapping">
<front>
<title>CPIM Mapping of SIMPLE Presence and Instant Messaging</title>
<author initials="J" surname="Rosenberg" fullname="Jonathan Rosenberg">
<organization />
</author>
<author initials="B" surname="Campbell" fullname="Ben Campbell">
<organization />
</author>
<date month="June" day="28" year="2002" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-simple-cpim-mapping-01" />
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-simple-cpim-mapping-01.txt" />
</reference>
<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="RFC3860">
<front>
<title>Common Profile for Instant Messaging (CPIM)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3860' />
<format type='TXT' octets='26486' target='ftp://ftp.isi.edu/in-notes/rfc3860.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="RFC3922">
<front>
<title>Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization>Jabber Software Foundation</organization>
</author>
<date year='2004' month='October' />
</front>
<seriesInfo name='RFC' value='3922' />
<format type='TXT' octets='70790' target='ftp://ftp.isi.edu/in-notes/rfc3922.txt' />
</reference>
</references>
<section title="Acknowledgements" anchor="ack">
<t>The authors wish to thank the following individuals for their feedback: Adrian Georgescu, Saul Ibarra, Salvatore Loreto, and Tory Patnoe.</t>
</section>
</back>
</rfc>