idnits 2.17.1
draft-saintandre-sip-xmpp-im-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
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 :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 8, 2009) is 5528 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-05) exists of
draft-saintandre-sip-xmpp-core-01
** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC
6120)
** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by
RFC 6121)
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 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
4 Intended status: Informational A. Houri
5 Expires: September 9, 2009 IBM
6 J. Hildebrand
7 Cisco
8 March 8, 2009
10 Interworking between the Session Initiation Protocol (SIP) and the
11 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
12 draft-saintandre-sip-xmpp-im-01
14 Status of this Memo
16 This Internet-Draft is submitted to IETF in full conformance with the
17 provisions of BCP 78 and BCP 79. This document may contain material
18 from IETF Documents or IETF Contributions published or made publicly
19 available before November 10, 2008. The person(s) controlling the
20 copyright in some of this material may not have granted the IETF
21 Trust the right to allow modifications of such material outside the
22 IETF Standards Process. Without obtaining an adequate license from
23 the person(s) controlling the copyright in such materials, this
24 document may not be modified outside the IETF Standards Process, and
25 derivative works of it may not be created outside the IETF Standards
26 Process, except to format it for publication as an RFC or to
27 translate it into languages other than English.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF), its areas, and its working groups. Note that
31 other groups may also distribute working documents as Internet-
32 Drafts.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/ietf/1id-abstracts.txt.
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html.
45 This Internet-Draft will expire on September 9, 2009.
47 Copyright Notice
48 Copyright (c) 2009 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents in effect on the date of
53 publication of this document (http://trustee.ietf.org/license-info).
54 Please review these documents carefully, as they describe your rights
55 and restrictions with respect to this document.
57 Abstract
59 This document defines a bi-directional protocol mapping for the
60 exchange of single instant messages between the Session Initiation
61 Protocol (SIP) and the Extensible Messaging and Presence Protocol
62 (XMPP).
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Instant Messages . . . . . . . . . . . . . . . . . . . . . . . 3
68 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 2.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 4
70 2.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 6
71 3. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8
72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
74 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
75 5.2. Informative References . . . . . . . . . . . . . . . . . . 10
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
78 1. Introduction
80 In order to help ensure interworking between instant messaging
81 systems that conform to the requirements of RFC 2779 [IMP-REQS], it
82 is important to clearly define protocol mappings between such
83 systems. Within the IETF, work has proceeded on two instant
84 messaging technologies:
86 o Various extensions to the Session Initiation Protocol ([SIP]) for
87 instant messaging, as developed within the SIP for Instant
88 Messaging and Presence Leveraging Extensions (SIMPLE) Working
89 Group; the relevant specification for instant messaging is
90 [SIP-IM]
91 o The Extensible Messaging and Presence Protocol (XMPP), which
92 consists of a formalization of the core XML streaming protocols
93 developed originally by the Jabber open-source community; the
94 relevant specifications are [XMPP] for the XML streaming layer and
95 [XMPP-IM] for basic presence and instant messaging extensions
97 One approach to helping ensure interworking between these protocols
98 is to map each protocol to the abstract semantics described in
99 [CPIM]; that is the approach taken by [SIMPLE-CPIM] and [XMPP-CPIM].
100 The approach taken in this document is to directly map semantics from
101 one protocol to another (i.e., from SIP/SIMPLE to XMPP and vice-
102 versa).
104 The architectural assumptions underlying such direct mappings are
105 provided in [SIP-XMPP], including mapping of addresses and error
106 condisions. The mappings specified in this document cover basic
107 instant messaging functionality, i.e., the exchange of a single
108 instant message between a SIP user and an XMPP user in either
109 direction. Mapping of more advanced functionality is out of scope
110 for this document, but other documents in this "series" cover such
111 topics.
113 Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED",
114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
115 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
116 interpreted as described in RFC 2119 [TERMS].
118 2. Instant Messages
120 2.1. Overview
122 Both XMPP and IM-aware SIP systems enable entities (often but not
123 necessarily human users) to send "instant messages" to other
124 entities. The term "instant message" usually refers to messages sent
125 between two entities for delivery in close to real time (rather than
126 messages that are stored and forwarded to the intended recipient upon
127 request). Generally there are three kinds of instant message:
129 o Single messages, which are sent from the sender to the recipient
130 outside the context of any one-to-one chat session or multi-user
131 text conference.
132 o Chat messages, which are sent from the sender to the recipient in
133 the context of a "messaging session" between the two entities.
134 o Groupchat messages, which are sent from a sender to multiple
135 recipients in the context of a text conference.
137 This document covers single messages only, since they form the
138 "lowest common denominator" for instant messaging on the Internet.
139 It is likely that future documents will address one-to-one chat
140 sessions and multi-user chat.
142 Instant messaging using XMPP message stanzas of type "normal" is
143 specified in [XMPP-IM]. Instant messaging using SIP requests of type
144 MESSAGE (often called "page-mode" messaging) is specified in
145 [SIP-IM].
147 As described in [XMPP-IM], a single instant message is an XML
148 stanza of type "normal" sent over an XML stream (since
149 "normal" is the default for the 'type' attribute of the
150 stanza, the attribute is often omitted). In this document we will
151 assume that such a message is sent from an XMPP client to an XMPP
152 server over an XML stream negotiated between the client and the
153 server, and that the client is controlled by a human user (this is a
154 simplifying assumption introduced for explanatory purposes only; the
155 XMPP sender could be a bot-controlled client, a component such as a
156 workflow application, a server, etc.). Continuing the tradition of
157 Shakespeare examples in XMPP documentation, we will say that the XMPP
158 user has an XMPP address of .
160 As described in [SIP-IM], a single instant message is a SIP MESSAGE
161 request sent from a SIP user agent to an intended recipient who is
162 most generally referenced by an Instant Message URI of the form
163 but who may be referenced by a SIP or SIPS URI of
164 the form or Here again we
165 introduce the simplifying assumption that the user agent is
166 controlled by a human user, whom we shall dub .
168 2.2. XMPP to SIP
170 When Juliet wants to send an instant message to Romeo, she interacts
171 with her XMPP client, which generates an XMPP stanza. The
172 syntax of the stanza, including required and optional
173 elements and attributes, is defined in [XMPP-IM]. The following is
174 an example of such a stanza:
176 Example: XMPP user sends message:
178 |
180 | Art thou not Romeo, and a Montague?
181 |
183 Upon receiving such a stanza, the XMPP server to which Juliet has
184 connected either delivers it to a local recipient (if the hostname in
185 the 'to' attribute matches one of the hostnames serviced by the XMPP
186 server) or attempts to route it to the foreign domain that services
187 the hostname in the 'to' attribute. Naturally, in this document we
188 assume that the hostname in the 'to' attribute is an IM-aware SIP
189 service hosted by a separate server. As specified in [XMPP-IM], the
190 XMPP server needs to determine the identity of the foreign domain,
191 which it does by performing one or more [SRV] lookups. For message
192 stanzas, the order of lookups recommended by [XMPP-IM] is to first
193 try the "_xmpp-server" service as specified in [XMPP] and to then try
194 the "_im" service as specified in [IMP-SRV]. Here we assume that the
195 first lookup will fail but that the second lookup will succeed and
196 return a resolution "_im._simple.example.net.", since we have already
197 assumed that the example.net hostname is running a SIP instant
198 messaging service. (Note: The XMPP server may have previously
199 determined that the foreign domain is a SIMPLE server, in which case
200 it would not need to perform the SRV lookups; the caching of such
201 information is a matter of implementation and local service policy,
202 and is therefore out of scope for this document.)
204 Once the XMPP server has determined that the foreign domain is
205 serviced by a SIMPLE server, it must determine how to proceed. We
206 here assume that the XMPP server contains or has available to it an
207 XMPP-SIMPLE gateway. The XMPP server would then deliver the message
208 stanza to the XMPP-SIMPLE gateway.
210 The XMPP-SIMPLE gateway is then responsible for translating the XMPP
211 message stanza into a SIP MESSAGE request from the XMPP user to the
212 SIP user:
214 Example: XMPP user sends message (SIP transformation):
216 | MESSAGE sip:romeo@example.net SIP/2.0
217 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
218 | Max-Forwards: 70
219 | From: sip:juliet@example.com;tag=49583
220 | To: sip:romeo@example.net
221 | Call-ID: Hr0zny9l3@example.com
222 | CSeq: 1 MESSAGE
223 | Content-Type: text/plain
224 | Content-Length: 35
225 |
226 | Art thou not Romeo, and a Montague?
228 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be
229 as shown in the following table. (Mappings for elements not
230 mentioned are undefined.)
232 Table 4: Message syntax mapping from XMPP to SIP
234 +-----------------------------+--------------------------+
235 | XMPP Element or Attribute | SIP Header or Contents |
236 +-----------------------------+--------------------------+
237 | | body of MESSAGE |
238 | | Subject |
239 | | Call-ID |
240 | from | From |
241 | id | (no mapping) |
242 | to | To |
243 | type | (no mapping) |
244 | xml:lang | Content-Language |
245 +-----------------------------+--------------------------+
247 2.3. SIP to XMPP
249 When Romeo wants to send an instant message to Juliet, he interacts
250 with his SIP user agent, which generates a SIP MESSAGE request. The
251 syntax of the MESSAGE request is defined in [SIP-IM]. The following
252 is an example of such a request:
254 Example: SIP user sends message:
256 | MESSAGE sip:juliet@example.com SIP/2.0
257 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
258 | Max-Forwards: 70
259 | From: sip:romeo@example.net;tag=38594
260 | To: sip:juliet@example.com
261 | Call-ID: M4spr4vdu@example.net
262 | CSeq: 1 MESSAGE
263 | Content-Type: text/plain
264 | Content-Length: 44
265 |
266 | Neither, fair saint, if either thee dislike.
268 Section 5 of [SIP-IM] stipulates that a SIP User Agent presented with
269 an im: URI should resolve it to a sip: or sips: URI. Therefore we
270 assume that the To header of a request received by a SIMPLE-XMPP
271 gateway will contain a sip: or sips: URI. The gateway SHOULD resolve
272 that address to an im: URI for SIP MESSAGE requests, then follow the
273 rules in [IMP-SRV] regarding the "_im" SRV service for the target
274 domain contained in the To header. If SRV address resolution fails
275 for the "_im" service, the gateway MAY attempt a lookup for the
276 "_xmpp-server" service as specified in [XMPP] or MAY return an error
277 to the sender (the SIP "502 Bad Gateway" error seems most
278 appropriate; see [SIP-XMPP] for details). If SRV address resolution
279 succeeds, the gateway is responsible for translating the request into
280 an XMPP message stanza from the SIP user to the XMPP user and
281 returning a SIP "200 OK" message to the sender:
283 Example: SIP user sends message (XMPP transformation):
285 |
287 | Neither, fair saint, if either thee dislike.
288 |
290 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be
291 as shown in the following table. (Mappings for elements not
292 mentioned in the foregoing table are undefined.)
293 Table 5: Message syntax mapping from SIP to XMPP
295 +--------------------------+-----------------------------+
296 | SIP Header or Contents | XMPP Element or Attribute |
297 +--------------------------+-----------------------------+
298 | Call-ID | |
299 | Content-Language | xml:lang |
300 | CSeq | (no mapping) |
301 | From | from |
302 | Subject | |
303 | To | to |
304 | body of MESSAGE | |
305 +--------------------------+-----------------------------+
307 Note: When transforming SIP page-mode messages, a SIMPLE-XMPP gateway
308 SHOULD specify no XMPP 'type' attribute or a 'type' attribute whose
309 value is "normal" (alternatively, the value of the 'type' attribute
310 MAY be "chat", although it SHOULD NOT be "headline" and MUST NOT be
311 "groupchat").
313 Note: See the Content Types (Section 3) of this document regarding
314 handling of SIP message bodies that contain content types other than
315 plain text.
317 3. Content Types
319 SIP requests of type MESSAGE may contain essentially any content
320 type. The recommended procedures for SIMPLE-to-XMPP gateways to use
321 in handling these content types are as follows.
323 A SIMPLE-to-XMPP gateway MUST process SIP messages that contain
324 message bodies of type "text/plain" and MUST encapsulate such message
325 bodies as the XML character data of the XMPP element.
327 A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain
328 message bodies of type "text/html"; if so, a gateway MUST transform
329 the "text/html" content into XHTML content that conforms to the XHTML
330 1.0 Integration Set specified in [XEP-0071].
332 A SIMPLE-to-XMPP gateway MAY process SIP messages that contain
333 message bodies of types other than "text/plain" and "text/html" but
334 handling of such content types is a matter of implementation.
336 4. Security Considerations
338 Detailed security considerations for instant messaging protocols are
339 given in [IMP-REQS], for SIP-based instant messaging in [SIP-IM] (see
340 also [SIP]), and for XMPP-based instant messaging in [XMPP-IM] (see
341 also [XMPP]).
343 This document specifies methods for exchanging instant messages
344 information through a gateway that translates between SIP and XMPP.
345 Such a gateway MUST be compliant with the minimum security
346 requirements of the instant messaging protocols for which it
347 translates (i.e., SIP and XMPP). The addition of gateways to the
348 security model of instant messaging specified in [IMP-REQS]
349 introduces some new risks. In particular, end-to-end security
350 properties (especially confidentiality and integrity) between instant
351 messaging user agents that interface through a SIMPLE-XMPP gateway
352 can be provided only if common formats are supported. Specification
353 of those common formats is out of scope for this document, although
354 it is recommended to use [MSGFMT] for instant messages.
356 [IMP-REQS] requires that conformant technologies shall include
357 methods for blocking communications from unwanted addresses. Such
358 blocking is the responsibility of conformant technology (e.g., XMPP
359 or SIP) and is out of scope for this memo.
361 5. References
363 5.1. Normative References
365 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging
366 and Presence", RFC 3861, August 2004.
368 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
369 A., Peterson, J., Sparks, R., Handley, M., and E.
370 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
371 June 2002.
373 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
374 and D. Gurle, "Session Initiation Protocol (SIP) Extension
375 for Instant Messaging", RFC 3428, December 2002.
377 [SIP-XMPP]
378 Saint-Andre, P., Houri, A., and J. Hildebrand,
379 "Interworking between the Session Initiation Protocol
380 (SIP) and the Extensible Messaging and Presence Protocol
381 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in
382 progress), March 2009.
384 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
385 specifying the location of services (DNS SRV)", RFC 2782,
386 February 2000.
388 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
389 Requirement Levels", BCP 14, RFC 2119, March 1997.
391 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
392 Protocol (XMPP): Core", RFC 3920, October 2004.
394 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
395 Protocol (XMPP): Instant Messaging and Presence",
396 RFC 3921, October 2004.
398 5.2. Informative References
400 [CPIM] Peterson, J., "Common Profile for Instant Messaging
401 (CPIM)", RFC 3860, August 2004.
403 [IMP-REQS]
404 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
405 / Presence Protocol Requirements", RFC 2779,
406 February 2000.
408 [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
409 Messaging (CPIM): Message Format", RFC 3862, August 2004.
411 [SIMPLE-CPIM]
412 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE
413 Presence and Instant Messaging",
414 draft-ietf-simple-cpim-mapping-01 (work in progress),
415 June 2002.
417 [XEP-0071]
418 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, January 2006.
420 [XMPP-CPIM]
421 Saint-Andre, P., "Mapping the Extensible Messaging and
422 Presence Protocol (XMPP) to Common Presence and Instant
423 Messaging (CPIM)", RFC 3922, October 2004.
425 Authors' Addresses
427 Peter Saint-Andre
428 Cisco
430 Email: psaintan@cisco.com
431 Avshalom Houri
432 IBM
433 Building 18/D, Kiryat Weizmann Science Park
434 Rehovot 76123
435 Israel
437 Email: avshalom@il.ibm.com
439 Joe Hildebrand
440 Cisco
442 Email: jhildebr@cisco.com