idnits 2.17.1
draft-ietf-xmpp-cpim-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
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 RFC 3978 Section 5.4 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 22, 2003) is 7615 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)
** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '1')
== Outdated reference: A later version (-04) exists of draft-ietf-impp-im-02
== Outdated reference: A later version (-04) exists of
draft-ietf-impp-pres-02
== Outdated reference: A later version (-24) exists of
draft-ietf-xmpp-core-13
== Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-12
== Outdated reference: A later version (-09) exists of
draft-ietf-xmpp-e2e-03
** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '9')
-- Obsolete informational reference (is this intentional?): RFC 2822 (ref.
'12') (Obsoleted by RFC 5322)
Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 4 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 Jabber Software Foundation
4 Expires: December 21, 2003 T. Bamonti
5 Jabber, Inc.
6 June 22, 2003
8 XMPP CPIM Mapping
9 draft-ietf-xmpp-cpim-00
11 Status of this Memo
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that other
18 groups may also distribute working documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on December 21, 2003.
33 Copyright Notice
35 Copyright (C) The Internet Society (2003). All Rights Reserved.
37 Abstract
39 This document describes a mapping of the Extensible Messaging and
40 Presence Protocol (XMPP) to the Common Presence and Instant Messaging
41 (CPIM) specifications.
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
46 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
47 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
48 1.3 Conventions Used in this Document . . . . . . . . . . . . 5
49 1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5
50 1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 5
51 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 6
52 3. Mapping of Instant Messages . . . . . . . . . . . . . . . 7
53 3.1 Identification of Instant Inboxes . . . . . . . . . . . . 7
54 3.2 Syntax Mapping from XMPP to CPIM Specifications . . . . . 7
55 3.2.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 7
56 3.2.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 8
57 3.2.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 8
58 3.2.4 XMPP Stanza ID . . . . . . . . . . . . . . . . . . . . . . 8
59 3.2.5 XMPP Message Type . . . . . . . . . . . . . . . . . . . . 8
60 3.2.6 XMPP Message Thread . . . . . . . . . . . . . . . . . . . 9
61 3.2.7 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 9
62 3.2.8 Message Subject . . . . . . . . . . . . . . . . . . . . . 9
63 3.2.9 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 9
64 3.2.10 CPIM Required Headers . . . . . . . . . . . . . . . . . . 10
65 3.2.11 MSGFMT MIME Content-type . . . . . . . . . . . . . . . . . 10
66 3.2.12 MSGFMT MIME Content-ID . . . . . . . . . . . . . . . . . . 10
67 3.2.13 Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
68 3.2.14 XMPP Message Extensions . . . . . . . . . . . . . . . . . 11
69 3.3 Syntax Mapping from CPIM Specifications to XMPP . . . . . 11
70 3.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 11
71 3.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 12
72 3.3.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 12
73 3.3.4 XMPP Message Type . . . . . . . . . . . . . . . . . . . . 12
74 3.3.5 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 12
75 3.3.6 Message Subject . . . . . . . . . . . . . . . . . . . . . 12
76 3.3.7 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 13
77 3.3.8 CPIM Required Headers . . . . . . . . . . . . . . . . . . 13
78 3.3.9 MSGFMT MIME Content-type . . . . . . . . . . . . . . . . . 13
79 3.3.10 MSGFMT MIME Content-ID . . . . . . . . . . . . . . . . . . 13
80 3.3.11 Message Body . . . . . . . . . . . . . . . . . . . . . . . 14
81 4. Mapping of Presence . . . . . . . . . . . . . . . . . . . 15
82 4.1 Identification of Presentities . . . . . . . . . . . . . . 15
83 4.2 Syntax Mapping from XMPP to CPIM Specifications . . . . . 15
84 4.2.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 15
85 4.2.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 16
86 4.2.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 17
87 4.2.4 XMPP Stanza ID . . . . . . . . . . . . . . . . . . . . . . 17
88 4.2.5 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 17
89 4.2.6 CPIM Subject Header . . . . . . . . . . . . . . . . . . . 17
90 4.2.7 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 17
91 4.2.8 CPIM Required Headers . . . . . . . . . . . . . . . . . . 18
92 4.2.9 PIDF MIME Content-type . . . . . . . . . . . . . . . . . . 18
93 4.2.10 PIDF MIME Content-ID . . . . . . . . . . . . . . . . . . . 18
94 4.2.11 XMPP Presence Type . . . . . . . . . . . . . . . . . . . . 18
95 4.2.12 XMPP Show Element . . . . . . . . . . . . . . . . . . . . 19
96 4.2.13 XMPP Status Element . . . . . . . . . . . . . . . . . . . 20
97 4.2.14 PIDF Contact Element . . . . . . . . . . . . . . . . . . . 21
98 4.2.15 Presence Priority . . . . . . . . . . . . . . . . . . . . 22
99 4.2.16 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 22
100 4.2.17 XMPP Presence Extensions . . . . . . . . . . . . . . . . . 22
101 4.3 Syntax Mapping from CPIM Specifications to XMPP . . . . . 23
102 4.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 23
103 4.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 23
104 4.3.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 24
105 4.3.4 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 24
106 4.3.5 CPIM Subject Header . . . . . . . . . . . . . . . . . . . 24
107 4.3.6 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 24
108 4.3.7 CPIM Required Headers . . . . . . . . . . . . . . . . . . 24
109 4.3.8 PIDF MIME Content-type . . . . . . . . . . . . . . . . . . 25
110 4.3.9 PIDF MIME Content-ID . . . . . . . . . . . . . . . . . . . 25
111 4.3.10 PIDF Basic Presence Status . . . . . . . . . . . . . . . . 25
112 4.3.11 PIDF Extended Status Information . . . . . . . . . . . . . 26
113 4.3.12 PIDF Note Element . . . . . . . . . . . . . . . . . . . . 27
114 4.3.13 PIDF Contact Element . . . . . . . . . . . . . . . . . . . 28
115 4.3.14 Presence Priority . . . . . . . . . . . . . . . . . . . . 29
116 4.3.15 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 29
117 5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . 30
118 5.1 Requesting a Subscription . . . . . . . . . . . . . . . . 30
119 5.2 Receiving a Subscription Request . . . . . . . . . . . . . 31
120 5.3 Subscription Durations . . . . . . . . . . . . . . . . . . 32
121 5.4 The Notify Operation . . . . . . . . . . . . . . . . . . . 32
122 5.5 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 33
123 5.6 Cancelling a Subscription . . . . . . . . . . . . . . . . 33
124 6. Mapping of Character Encodings . . . . . . . . . . . . . . 35
125 7. Security Considerations . . . . . . . . . . . . . . . . . 36
126 Normative References . . . . . . . . . . . . . . . . . . . 37
127 Informative References . . . . . . . . . . . . . . . . . . 38
128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
129 Intellectual Property and Copyright Statements . . . . . . 39
131 1. Introduction
133 1.1 Overview
135 The Instant Messaging and Presence (IMPP) Working Group has defined
136 an abstract framework for interoperability among instant messaging
137 and presence systems that are compliant with RFC 2779 [1]. This
138 framework is commonly called Common Presence and Instant Messaging or
139 "CPIM". The CPIM specifications include a Common Profile for Instant
140 Messaging [2] (also called CPIM), a Common Profile for Presence [3]
141 (CPP), a CPIM Message Format [4] (MSGFMT), and a Common Presence
142 Information Data Format [5] (PIDF). (Note: to prevent confusion,
143 Common Presence and Instant Messaging is referred to herein
144 collectively as "the CPIM specifications", whereas the Common Profile
145 for Instant Messaging is referred to as "CPIM". However, the term
146 "XMPP-CPIM Gateway" is used to refer to a gateway between a XMPP
147 service and a non-XMPP service, where the common format is defined by
148 the CPIM specifications.)
150 This document describes how the Extensible Messaging and Presence
151 Protocol (XMPP Core [6], XMPP IM [7]) maps to the abstract model
152 contained in the CPIM specifications, mainly for the purpose of
153 establishing gateways between XMPP services and non-XMPP instant
154 messaging (IM) services that conform to RFC 2779 [1]. Such gateways
155 may be established to interpret the protocols of one service and
156 translate them into the protocols of the other service. In the case
157 of communications between an XMPP service and a non-XMPP service, we
158 can visualize this relationship as follows:
160 +-------------+ +-------------+ +------------+
161 | | | | | |
162 | XMPP | | XMPP-CPIM | | Non-XMPP |
163 | Service | <----> | Gateway | <----> | Service |
164 | | | | | |
165 +-------------+ +-------------+ +------------+
167 This document defines a mapping for use by a gateway that translates
168 between XMPP and a non-XMPP protocol via the CPIM specifications.
169 Such a gateway is not an intermediate hop on a network of non-XMPP
170 servers (whose native formats may or may not be defined by the CPIM
171 specifications), but a dedicated translator between XMPP and a
172 non-XMPP protocol, where the CPIM specifications define the common
173 formats into which the protocols are translated for purposes of
174 interworking.
176 The mapping defined herein applies to instant messages and presence
177 information that are not encrypted or signed for end-to-end security.
178 For information about secure communications to or from an XMPP
179 service through an XMPP-CPIM gateway, refer to End-to-End Object
180 Encryption in XMPP [8].
182 1.2 Terminology
184 This memo inherits vocabulary defined in RFC 2778 [9]. Terms such as
185 CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
186 PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
187 defined therein.
189 This memo also inherits vocabulary defined in XMPP Core [6]. Terms
190 such as ENTITY, JID, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
191 IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
192 meaning as defined therein.
194 1.3 Conventions Used in this Document
196 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
197 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
198 "OPTIONAL" in this document are to be interpreted as described in RFC
199 2119 [10].
201 1.4 Discussion Venue
203 The authors welcome discussion and comments related to the topics
204 presented in this document. The preferred forum is the
205 mailing list, for which archives and subscription
206 information are available at .
209 1.5 Intellectual Property Notice
211 This document is in full compliance with all provisions of Section 10
212 of RFC 2026. Parts of this specification use the term "jabber" for
213 identifying namespaces and other protocol syntax. Jabber[tm] is a
214 registered trademark of Jabber, Inc. Jabber, Inc. grants permission
215 to the IETF for use of the Jabber trademark in association with this
216 specification and its successors, if any.
218 2. Approach
220 XMPP and CPIM are distinctly foreign technologies. Therefore, care
221 must be taken in mapping between XMPP and the abstract syntax defined
222 by the CPIM specifications.
224 At root, XMPP is a data transport protocol for streaming XML
225 fragments (called "stanzas") between any two endpoints on the
226 network; message and presence stanzas are two of the core data
227 elements defined in XMPP and are often used to exchange instant
228 messages and presence information between IM users (although the
229 inherent extensibility of XML enables applications to use the general
230 semantics of these stanza types for other purposes). XMPP is not
231 based on MIME [11]; instead, XMPP Core [6] defines XML schemas for
232 both message and presence stanzas (for example, the child of
233 a message stanza contains XML character data that is usually intended
234 to be read by a human user).
236 The CPIM specifications provide common formats for instant messaging
237 and presence through two MIME [11] content-types: "Message/CPIM" for
238 messages (MSGFMT [4]) and "application/pidf+xml" for presence (PIDF
239 [5]). The syntax of "Message/CPIM" objects is similar to but stricter
240 than that of RFC 2822 [12], and includes the ability to include
241 arbitrary MIME media types [13]. By contrast, each "application/
242 pidf+xml" object is a complete XML document whose structure is
243 defined by an XML schema.
245 The approach taken herein is to specify mappings from XMPP elements
246 and attributes to the headers and MIME formats defined by MSGFMT [4]
247 and PIDF [5] in order to comply with the semantics defined by CPIM
248 [2] and CPP [3]. Naturally, mappings in the opposite direction are
249 provided as well.
251 3. Mapping of Instant Messages
253 This section describes how a gateway SHOULD map instant messages
254 between an XMPP service and a non-XMPP service using a "Message/CPIM"
255 object as the bearer of encapsulated text content in order to comply
256 with the instant messaging semantics defined by CPIM [2].
258 3.1 Identification of Instant Inboxes
260 There is a one-to-one relationship between an XMPP entity and a CPIM
261 instant inbox when the JID of the entity contains only a node
262 identifier and domain identifier, and the node identifier uniquely
263 corresponds to an IM user who possesses an account on an XMPP server.
265 3.2 Syntax Mapping from XMPP to CPIM Specifications
267 This section defines the mapping of syntax primitives from XMPP
268 message stanzas to "Message/CPIM" objects with encapsulated text
269 content.
271 3.2.1 From Address
273 The 'from' attribute of an XMPP message stanza maps to the 'From'
274 header of a "Message/CPIM" object. In XMPP, the sender MUST NOT
275 include a 'from' attribute; instead, the sender's server stamps the
276 "from" address and sets its value to the full authzid (including
277 resource identifier) provided by the client when authenticating. Thus
278 an XMPP-CPIM gateway will receive from the sender's XMPP server a
279 message stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP message stanza to
281 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
282 the resource identifier, MUST append the "im:" Instant Messaging URI
283 scheme to the front of the address, and MAY include a CPIM
284 "Formal-name" for the sender (if known).
286 Example: From Address Mapping
288 XMPP 'from' attribute
289
290 ...
291
293 CPIM 'From' header
294 From:
296 3.2.2 To Address
298 The 'to' attribute of an XMPP message stanza maps to the 'To' header
299 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 'to'
300 attribute on a message stanza, and MUST include it if the message is
301 intended for delivery to another user. Thus an XMPP-CPIM gateway will
302 receive from the sender's XMPP server a message stanza containing a
303 "to" address of the form or . To
304 map the 'to' attribute of an XMPP message stanza to the 'To' header
305 of a "Message/CPIM" object, the gateway MUST remove the resource
306 identifier (if included), MUST append the "im:" Instant Messaging URI
307 scheme to the front of the address, and MAY include a CPIM
308 "Formal-name" for the recipient (if known).
310 Example: To Address Mapping
312 XMPP 'to' attribute
313
314 ...
315
317 CPIM 'To' header
318 To:
320 3.2.3 CPIM Courtesy Copy
322 The core XMPP specification does not include syntax for specifying a
323 "courtesy copy" (non-primary addressee) for a message stanza.
324 Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of
325 a "Message/CPIM" object.
327 3.2.4 XMPP Stanza ID
329 An XMPP message stanza MAY possess an 'id' attribute, which is used
330 by the sending application for the purpose of tracking stanzas. There
331 is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header,
332 common MIME features, or encapsulated text content. Therefore if an
333 XMPP stanza received by an XMPP-CPIM gateway possesses an 'id'
334 attribute, the gateway SHOULD ignore the value provided.
336 3.2.5 XMPP Message Type
338 An XMPP message stanza MAY possess a 'type' attribute, which is used
339 by the sending application to capture the conversational context of
340 the message. There is no mapping of an XMPP 'type' attribute to a
341 "Message/CPIM" header, common MIME features, or encapsulated text
342 content. Therefore if an XMPP stanza received by an XMPP-CPIM gateway
343 possesses a 'type' attribute, the gateway SHOULD ignore the value
344 provided.
346 3.2.6 XMPP Message Thread
348 An XMPP message stanza MAY contain a child element to
349 specify the conversation thread in which the message is situated.
350 There is no mapping of an XMPP element to a "Message/CPIM"
351 header, common MIME features, or encapsulated text content. Therefore
352 if an XMPP message stanza received by an XMPP-CPIM gateway contains a
353 child element, the gateway SHOULD ignore the value
354 provided.
356 3.2.7 CPIM DateTime Header
358 The core XMPP specification does not include syntax for specifying
359 the datetime at which a message stanza was sent. However, an
360 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
361 CPIM" object it generates, the value of which SHOULD be the datetime
362 at which the message stanza was received for processing by the
363 gateway.
365 3.2.8 Message Subject
367 An XMPP message stanza MAY include a child element. If
368 included, it maps to the 'Subject' header of a "Message/CPIM" object.
369 The element MAY include an 'xml:lang' attribute specifying
370 the language in which the subject is written. To map the XMPP
371 element to the 'Subject' header of a "Message/CPIM"
372 object, the gateway SHOULD simply map the XMPP CDATA to the value of
373 the 'Subject' header. If an 'xml:lang' attribute is provided, it MUST
374 be mapped by including ';lang=tag' after the header name and colon,
375 where 'tag' is the value of the 'xml:lang' attribute.
377 Example: Subject Mapping
379 XMPP element
380 Hi!
381 Ahoj!
383 CPIM 'Subject' header
384 Subject: Hi!
385 Subject:;lang=cz Ahoj!
387 3.2.9 CPIM Header Extensions
389 A "Message/CPIM" object MAY include an optional 'NS' header to
390 specify the namespace of a feature extension. An XMPP-CPIM gateway
391 SHOULD NOT generate such headers.
393 3.2.10 CPIM Required Headers
395 A "Message/CPIM" object MAY include an optional 'Required' header to
396 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
397 NOT generate such headers.
399 3.2.11 MSGFMT MIME Content-type
401 RFC 2045 [11] specifies that the default Content-type of a MIME
402 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
403 uses a different character encoding (either UTF-8 or UTF-16 depending
404 on stream negotiation), the encapsulated MIME object generated by an
405 XMPP-CPIM gateway MUST set the 'Content-type' header for that object.
406 The "Content-type" MUST be set to "text/plain" and the charset MUST
407 be set to the character encoding negotiated for the XML stream used
408 by the sender, i.e., either UTF-8 or UTF-16.
410 Example: Content-type for Encapsulated Object
412 Content-type: text/plain; charset=utf-8
414 3.2.12 MSGFMT MIME Content-ID
416 RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME
417 objects. While an XMPP-CPIM gateway MAY generate a Content-ID for
418 encapsulated MIME objects, it is NOT REQUIRED to do so. If included,
419 Content-ID values MUST be generated to be world-unique.
421 Example: Content-ID for Encapsulated Object
423 Content-ID: <123456789@montague.net>
425 3.2.13 Message Body
427 The child element of an XMPP message stanza is used to
428 provide the primary meaning of the message. The CDATA of the XMPP
429 element maps to the encapsulated text message content.
431 Example: Message Body
433 XMPP message
434
435 Wherefore art thou, Romeo?
436
438 Encapsulated MIME text content
439 Content-type: text/plain; charset=utf-8
440 Content-ID: <123456789@montague.net>
442 Wherefore art thou, Romeo?
444 3.2.14 XMPP Message Extensions
446 As defined in XMPP Core [6], an XMPP message stanza may contain
447 "extended" content in any namespace in order to supplement or extend
448 the semantics of the core message stanza. With the exception of
449 extended information qualified by the
450 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End
451 Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore
452 such information and not pass it through the gateway to the intended
453 recipient. No mapping for such information is defined.
455 3.3 Syntax Mapping from CPIM Specifications to XMPP
457 This section defines the mapping of syntax primitives from "Message/
458 CPIM" objects with encapsualted text content to XMPP message stanzas.
460 3.3.1 From Address
462 The 'From' header of a "Message/CPIM" object maps to the 'from'
463 attribute of an XMPP message stanza. To map the CPIM 'From' header to
464 the XMPP 'from' attribute, the gateway MUST remove the "im:" Instant
465 Messaging URI scheme from the front of the address and MUST remove
466 the CPIM "Formal-name" (if provided).
468 Example: From Address Mapping
470 CPIM 'From' header
471 From: Romeo Montague
473 XMPP 'from' attribute
474
475 ...
476
478 3.3.2 To Address
480 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
481 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP
482 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
483 URI scheme from the front of the address and MUST remove the CPIM
484 "Formal-name" (if provided). If the gateway possesses knowledge of
485 the resource identifier in use by the XMPP entity, the gateway MAY
486 append the resource identifier to the address.
488 Example: To Address Mapping
490 CPIM 'To' header
491 To: Juliet Capulet
493 XMPP 'to' attribute
494
495 ...
496
498 3.3.3 CPIM Courtesy Copy
500 The core XMPP specification does not include syntax for specifying a
501 "courtesy copy" (non-primary addressee) for a message stanza.
502 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
503 that contains a 'cc' header, it MUST NOT pass that information on to
504 the XMPP recipient.
506 3.3.4 XMPP Message Type
508 MSGFMT does not possess the concept of a message type that can map to
509 the XMPP 'type' attribute for message stanzas. Therefore an XMPP-CPIM
510 gateway SHOULD NOT include the 'type' attribute on the messages it
511 sends to XMPP recipients.
513 3.3.5 CPIM DateTime Header
515 The core XMPP specification does not include syntax for specifying
516 the datetime at which a message stanza was sent. Therefore, if an
517 XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
518 'DateTime' header, it SHOULD NOT pass that information on to the XMPP
519 recipient.
521 3.3.6 Message Subject
523 The 'Subject' header of a "Message/CPIM" object maps to the child element of a XMPP message stanza. The 'Subject' header MAY
525 specify the "lang" in which the subject is written. To map the CPIM
526 'Subject' header to the XMPP element, the gateway SHOULD
527 simply map the value of the 'Subject' header to the XMPP CDATA. If
528 "lang" information is provided, it MUST be mapped to the 'xml:lang'
529 attribute of the element, where the value of the
530 'xml:lang' attribute is the the "tag" value supplied in the string
531 ';lang=tag' included CPIM 'Subject' header name and colon.
533 Example: Subject Mapping
535 CPIM 'Subject' header
536 Subject: Hi!
537 Subject:;lang=cz Ahoj!
539 XMPP element
540 Hi!
541 Ahoj!
543 3.3.7 CPIM Header Extensions
545 "Message/CPIM" objects MAY include an optional 'NS' header to specify
546 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
547 pass such headers through to the XMPP recipient, and no mapping for
548 such headers is defined.
550 3.3.8 CPIM Required Headers
552 "Message/CPIM" objects MAY include an optional 'Required' header to
553 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
554 NOT pass such headers through to the XMPP recipient, and no mapping
555 for such headers is defined.
557 3.3.9 MSGFMT MIME Content-type
559 CPIM [4] specifies that a "Message/CPIM" object MAY contain any
560 arbitrary MIME content. However, support for arbitrary content types
561 is not a requirement in XMPP; in particular, the child
562 element of an XMPP message stanza MUST contain XML character data
563 only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP message
564 stanza a "Message/CPIM" object whose encapsulated MIME object has a
565 Content-type other than "text/plain" (with the exception of
566 multi-part MIME objects used for End-to-End Object Encryption in XMPP
567 [8]).
569 3.3.10 MSGFMT MIME Content-ID
571 XMPP does not include an element or attribute that captures a
572 globally unique ID as is defined for the Content-ID MIME header as
573 specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME
574 object that includes a Content-ID, it MAY provide the Content-ID as
575 the value of the message stanza's 'id' attribute but is NOT REQUIRED
576 to do so.
578 Example: Content-ID for Encapsulated Object
580 MIME header
581 Content-ID: <123456789@montague.net>
583 XMPP 'id' attribute (OPTIONAL)
584
585 ...
586
588 3.3.11 Message Body
590 If the Content-type of an encapsulated MIME object is "text/plain",
591 then the encapsulated text message content maps to the CDATA of the
592 child element of an XMPP message stanza.
594 Example: Message Body
596 Encapsulated MIME text content
597 Content-type: text/plain; charset=utf-8
598 Content-ID: <123456789@montague.net>
600 Wherefore art thou?
602 XMPP message
603
604 Wherefore art thou?
605
607 4. Mapping of Presence
609 This section describes how a gateway SHOULD map presence information
610 between an XMPP service and a non-XMPP service using a "Message/CPIM"
611 object as the bearer of an encapsulated PIDF [5] object in order to
612 comply with the presence semantics defined by CPP [3].
614 4.1 Identification of Presentities
616 There is a one-to-one relationship between an XMPP entity and a CPP
617 presentity when the JID of the entity contains only a node identifier
618 and domain identifier, and the node identifier uniquely corresponds
619 to an IM user who possesses an account on an XMPP server.
621 4.2 Syntax Mapping from XMPP to CPIM Specifications
623 This section defines the mapping of syntax primitives from XMPP
624 presence stanzas to "Message/CPIM" objects with encapsulated
625 "application/pidf+xml" objects.
627 4.2.1 From Address
629 The 'from' attribute of an XMPP presence stanza maps to the 'From'
630 header of a "Message/CPIM" object. In XMPP, the sender MUST NOT
631 include a 'from' attribute; instead, the sender's server stamps the
632 "from" address and sets its value to the full authzid (including
633 resource identifier) provided by the client when authenticating. Thus
634 an XMPP-CPIM gateway will receive from the sender's XMPP server a
635 presence stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP presence stanza to
637 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
638 the resource identifier, MUST append the "im:" Instant Messaging URI
639 scheme to the front of the address, and MAY include a CPIM
640 "Formal-name" for the sender (if known).
642 Example: From Address Mapping
644 XMPP 'from' attribute
645
646 ...
647
649 CPIM 'From' header
650 From:
652 In addition, the 'from' attribute of an XMPP presence stanza maps to
653 the 'entity' attribute of a PIDF root element. To map the
654 XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
655 MUST remove the resource identifier and MUST append the "pres:"
656 Instant Messaging URI scheme to the front of the address.
658 Example: From Address Mapping (PIDF)
660 XMPP 'from' attribute
661
662 ...
663
665 PIDF 'entity' attribute
666
667 ...
668
670 Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
671 the JID contained in the XMPP 'from' attribute to the 'id' attribute
672 of the PIDF child element.
674 Example: Resource Identifier Mapping
676 XMPP 'from' attribute
677
678 ...
679
681 PIDF 'id' for
682
683
684 ...
685
686
688 4.2.2 To Address
690 The 'to' attribute of an XMPP presence stanza maps to the 'To' header
691 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 'to'
692 attribute on a presence stanza, and MUST include it if the presence
693 is intended for delivery to another user. Thus an XMPP-CPIM gateway
694 will receive from the sender's XMPP server a presence stanza
695 containing a "to" address of the form or . To map the 'to' attribute of an XMPP presence stanza to
697 the 'To' header of a "Message/CPIM" object, the gateway MUST remove
698 the resource identifier (if included), MUST append the "im:" Instant
699 Messaging URI scheme to the front of the address, and MAY include a
700 CPIM "Formal-name" for the recipient (if known).
702 Example: To Address Mapping
704 XMPP 'to' attribute
705
706 ...
707
709 CPIM 'To' header
710 To:
712 4.2.3 CPIM Courtesy Copy
714 The core XMPP specification does not include syntax for specifying a
715 "courtesy copy" (non-primary addressee) for a presence stanza.
716 Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of
717 a "Message/CPIM" object.
719 4.2.4 XMPP Stanza ID
721 An XMPP presence stanza MAY possess an 'id' attribute, which is used
722 by the sending application for the purpose of tracking stanzas. There
723 is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header,
724 common MIME features, or encapsulated text content. Therefore if an
725 XMPP stanza received by an XMPP-CPIM gateway possesses an 'id'
726 attribute, the gateway SHOULD ignore the value provided.
728 4.2.5 CPIM DateTime Header
730 The core XMPP specification does not include syntax for specifying
731 the datetime at which a presence stanza was sent. However, an
732 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
733 CPIM" object it generates, the value of which SHOULD be the datetime
734 at which the presence stanza was received for processing by the
735 gateway.
737 4.2.6 CPIM Subject Header
739 An XMPP presence stanza contains no information that can be mapped to
740 the 'Subject' header of a "Message/CPIM" object. Therefore an
741 XMPP-CPIM gateway SHOULD NOT generate such headers when mapping XMPP
742 presence stanzas.
744 4.2.7 CPIM Header Extensions
746 A "Message/CPIM" object MAY include an optional 'NS' header to
747 specify the namespace of a feature extension. An XMPP-CPIM gateway
748 SHOULD NOT generate such headers.
750 4.2.8 CPIM Required Headers
752 A "Message/CPIM" object MAY include an optional 'Required' header to
753 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
754 NOT generate such headers.
756 4.2.9 PIDF MIME Content-type
758 RFC 2045 [11] specifies that the default Content-type of a MIME
759 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
760 uses a different character encoding (either UTF-8 or UTF-16 depending
761 on stream negotiation) and because PIDF specifies the "application/
762 pidf+xml" MIME time, the encapsulated MIME object generated by an
763 XMPP-CPIM gateway for presence information MUST set the
764 'Content-type' header for that object. The "Content-type" MUST be set
765 to "application/pidf+xml" and the charset MUST be set to the
766 character encoding negotiated for the XML stream used by the sender,
767 i.e., either UTF-8 or UTF-16.
769 Example: Content-type for Encapsulated PIDF Object
771 Content-type: application/pidf+xml; charset=utf-8
773 4.2.10 PIDF MIME Content-ID
775 RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME
776 objects. While an XMPP-CPIM gateway MAY generate a Content-ID for
777 encapsulated MIME objects, it is NOT REQUIRED to do so. If included,
778 Content-ID values MUST be generated to be world-unique.
780 Example: Content-ID for Encapsulated Object
782 Content-ID: <123456789@montague.net>
784 4.2.11 XMPP Presence Type
786 An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
787 attribute is included, the presence stanza indicates that the sender
788 is available; this state maps to the PIDF basic presence type of
789 OPEN. If the 'type' attribute has a value of "unavailable", the
790 presence stanza indicates that the sender is no longer available;
791 this state maps to the PIDF basic presence type of CLOSED. Thus both
792 the absence of a 'type' attribute and a 'type' attribute set to a
793 value of "unavailable" correspond to the CPP [3] "notify operation".
794 All other presence types are used to manage presence subscriptions or
795 probe for current presence; mappings for these other presence types
796 are defined under XMPP-CPIM Gateway as Presence Service (Section 5).
798 Example: Available Presence
800 XMPP available presence
801
803 PIDF basic presence (OPEN)
804
805
807
808
809 open
810
811
812
814 Example: Unavailable Presence
816 XMPP unavailable presence
817
819 PIDF basic presence (CLOSED)
820
821
823
824
825 closed
826
827
828
830 4.2.12 XMPP Show Element
832 The child element of an XMPP presence stanza provides
833 additional information about the sender's availability. The CDATA of
834 the XMPP element maps to extended content in PIDF.
835 The defined values of the element are 'away', 'chat', 'dnd',
836 and 'xa'; as soon as values are specified for extended status states
837 in the 'urn:ietf:params:xml:ns:pidf:im' namespace, the XMPP values
838 will be mapped to the PIDF values.
840 Example: Show Element
842 XMPP element
843
844 away
845
847 PIDF extended presence information
848
849
852
853
854 open
855 away
856
857
858
860 4.2.13 XMPP Status Element
862 The child element of an XMPP presence stanza provides a
863 user-defined, natural-language description of the sender's detailed
864 availability state. The XMPP element maps to the PIDF
865 child of the PIDF element.
867 Example: Status Element
869 XMPP element
870
871 away
872 retired to the chamber
873
875 PIDF element
876
877
880
881
882 open
883 away
884
885 retired to the chamber
886
887
889 4.2.14 PIDF Contact Element
891 The core XMPP specification does not include syntax for specifying
892 the URL of a contact address, since the contact address is implicit
893 in the 'from' attribute of the XMPP presence stanza. However, an
894 XMPP-CPIM gateway MAY include the child of the
895 element, the value of which SHOULD be the bare JID () of
896 the XMPP sender, prepended by the "im:" Instant Messaging URI scheme.
898 Example: PIDF Contact Element
900 XMPP presence stanza
901
903 PIDF element
904
905
907
908 ...
909 im:juliet@capulet.com
910
911
913 4.2.15 Presence Priority
915 An XMPP presence stanza MAY contain a child element whose
916 value is an integer between -128 and +127. The value of this element
917 MAY be mapped to the 'priority' attribute of the child of
918 the PIDF element. If the value of the XMPP
919 element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
920 range of allowable values for the PIDF 'priority' attribute is any
921 decimal number from zero to one inclusive, with a maximimum of three
922 decimal places. If an XMPP-CPIM gateway maps these values, it SHOULD
923 treat XMPP 0 as PIDF priority='0' and
924 127 as PIDF priority='1', mapping intermediate
925 values appropriately so that they are unique (e.g., XMPP priority 1
926 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
927 so on up through mapping XMPP priority 126 to PIDF priority 0.992;
928 note that this is an example only, and that the exact mapping shall
929 be determined by the XMPP-CPIM gateway).
931 Example: Presence Priority
933 XMPP element
934
935 13
936
938 PIDF element
939
940
942
943 ...
944 im:juliet@capulet.com
945
946
948 4.2.16 PIDF Timestamp Element
950 The core XMPP specification does not include syntax for specifying
951 the datetime at which a presence stanza was sent. However, an
952 XMPP-CPIM gateway MAY include a element within the PIDF
953 document it generates, the value of which SHOULD be the datetime at
954 which the presence stanza was received for processing by the gateway.
956 4.2.17 XMPP Presence Extensions
958 As defined in XMPP Core [6], an XMPP presence stanza may contain
959 "extended" content in any namespace in order to supplement or extend
960 the semantics of the core presence stanza. With the exception of
961 extended information qualified by the
962 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End
963 Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore
964 such information and not pass it through the gateway to the intended
965 recipient. No mapping for such information is defined.
967 4.3 Syntax Mapping from CPIM Specifications to XMPP
969 This section defines the mapping of syntax primitives from "Message/
970 CPIM" objects with encapsulated "application/pidf+xml" objects to
971 XMPP presence stanzas.
973 4.3.1 From Address
975 The 'From' header of a "Message/CPIM" object maps to the 'from'
976 attribute of an XMPP presence stanza. To map the CPIM 'From' header
977 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
978 Instant Messaging URI scheme from the front of the address and MUST
979 remove the CPIM "Formal-name" (if provided).
981 Example: From Address Mapping
983 CPIM 'From' header
984 From: Romeo Montague
986 XMPP 'from' attribute
987
988 ...
989
991 4.3.2 To Address
993 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
994 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
995 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
996 URI scheme from the front of the address and MUST remove the CPIM
997 "Formal-name" (if provided). If the gateway possesses knowledge of
998 the resource identifier in use by the XMPP entity, the gateway MAY
999 append the resource identifier to the address.
1001 Example: To Address Mapping
1003 CPIM 'To' header
1004 To: Juliet Capulet
1006 XMPP 'to' attribute
1007
1008 ...
1009
1011 4.3.3 CPIM Courtesy Copy
1013 The core XMPP specification does not include syntax for specifying a
1014 "courtesy copy" (non-primary addressee) for a presence stanza.
1015 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1016 with encapsulated PIDF object that contains a 'cc' header, it MUST
1017 NOT pass that information on to the XMPP recipient.
1019 4.3.4 CPIM DateTime Header
1021 The core XMPP specification does not include syntax for specifying
1022 the datetime at which a presence stanza was sent. Therefore, if an
1023 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1024 PIDF object that contains a 'DateTime' header, it SHOULD NOT pass
1025 that information on to the XMPP recipient.
1027 4.3.5 CPIM Subject Header
1029 An XMPP presence stanza contains no information that can be mapped to
1030 the 'Subject' header of a "Message/CPIM" object. Therefore, if an
1031 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1032 PIDF object that contains a 'Subject' header, it SHOULD NOT pass that
1033 information on to the XMPP recipient.
1035 4.3.6 CPIM Header Extensions
1037 "Message/CPIM" objects MAY include an optional 'NS' header to specify
1038 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
1039 pass such headers through to the XMPP recipient, and no mapping for
1040 such headers is defined.
1042 4.3.7 CPIM Required Headers
1044 "Message/CPIM" objects MAY include an optional 'Required' header to
1045 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
1046 NOT pass such headers through to the XMPP recipient, and no mapping
1047 for such headers is defined.
1049 4.3.8 PIDF MIME Content-type
1051 CPIM [4] specifies that a "Message/CPIM" object MAY contain any
1052 arbitrary MIME content. However, support for arbitrary content types
1053 is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to an
1054 XMPP presence stanza a "Message/CPIM" object whose encapsulated MIME
1055 object has a Content-type other than "application/pidf+xml" (with the
1056 exception of multi-part MIME objects used for End-to-End Object
1057 Encryption in XMPP [8]).
1059 4.3.9 PIDF MIME Content-ID
1061 XMPP does not include an element or attribute that captures a
1062 globally unique ID as is defined for the Content-ID MIME header as
1063 specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME
1064 object that includes a Content-ID, it MAY provide the Content-ID as
1065 the value of the presence stanza's 'id' attribute but is NOT REQUIRED
1066 to do so.
1068 Example: Content-ID for Encapsulated Object
1070 MIME header
1071 Content-ID: <123456789@montague.net>
1073 XMPP 'id' attribute (OPTIONAL)
1074
1075 ...
1076
1078 4.3.10 PIDF Basic Presence Status
1080 The basic presence status types defined in PIDF are OPEN and CLOSED.
1081 The PIDF basic presence status of OPEN maps to an XMPP presence
1082 stanza that possesses no 'type' attribute (indicating default
1083 availability). The PIDF basic presence status of CLOSED maps to an
1084 XMPP presence stanza that possesses a 'type' attribute with a value
1085 of "unavailable".
1087 Example: OPEN Presence
1089 PIDF basic presence (OPEN)
1090
1091
1093
1094
1095 open
1096
1097
1098
1100 XMPP available presence
1101
1103 Example: CLOSED Presence
1105 PIDF basic presence (CLOSED)
1106
1107
1109
1110
1111 closed
1112
1113
1114
1116 XMPP unavailable presence
1117
1120 4.3.11 PIDF Extended Status Information
1122 PIDF documents may contain extended content. As of this
1123 writing there are no pre-defined extended status states that
1124 correspond to the defined values of the XMPP element ('away',
1125 'chat', 'dnd', and 'xa'); as soon as values are specified for
1126 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
1127 namespace, the PIDF values will be mapped to the relevant XMPP
1128 values.
1130 Example: Extended Status Information (provisional)
1132 PIDF extended presence information
1133
1134
1137
1138
1139 open
1140 busy
1141
1142
1143
1145 XMPP element
1146
1147 dnd
1148
1150 4.3.12 PIDF Note Element
1152 A PIDF element may contain a child that provides a
1153 user-defined, natural-language description of the sender's detailed
1154 availability state. The PIDF element maps to the XMPP
1155 element.
1157 Example: Note Element
1159 PIDF element
1160
1161
1164
1165
1166 open
1167 busy
1168
1169 Wooing Juliet
1170
1171
1173 XMPP element
1174
1175 dnd
1176 Wooing Juliet
1177
1179 4.3.13 PIDF Contact Element
1181 The core XMPP specification does not include syntax for specifying
1182 the URL of a contact address, since the contact address is implicit
1183 in the 'from' attribute of the XMPP presence stanza. Therefore, if an
1184 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1185 PIDF object that contains a element, it SHOULD NOT pass
1186 the CDATA of the element on to the XMPP recipient.
1187 However, the gateway MAY map the 'priority' element as specified in
1188 the following section.
1190 Example: PIDF Contact Element
1192 PIDF element
1193
1194
1196
1197 ...
1198 im:romeo@montague.net
1199
1200
1202 XMPP presence stanza
1203
1205 4.3.14 Presence Priority
1207 The child of the PIDF element MAY possess a
1208 'priority' attribute whose value is a decimal number between zero and
1209 one (with a maximum of three decimal places). The value of this
1210 attribute MAY be mapped to the child element of an XMPP
1211 presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
1212 values to negative values of the XMPP element. If an
1213 XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
1214 priority='0' as XMPP 0 and PIDF priority='1' as
1215 127, mapping intermediate values appropriately
1216 so that they are unique (e.g., PIDF priorities between 0.001 and
1217 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to
1218 XMPP priority 2, and so on up through mapping PIDF priorities between
1219 0.992 and 0.999 to XMPP priority 126; note that this is an example
1220 only, and that the exact mapping shall be determined by the XMPP-CPIM
1221 gateway).
1223 4.3.15 PIDF Timestamp Element
1225 The core XMPP specification does not include syntax for specifying
1226 the datetime or timestamp at which a presence stanza was sent.
1227 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1228 with encapsulated PIDF object that contains a element,
1229 it SHOULD NOT pass that information on to the XMPP recipient.
1231 5. XMPP-CPIM Gateway as Presence Service
1233 CPP [3] defines semantics for an abstract presence service. An
1234 XMPP-CPIM gateway MAY function as such a presence service, and if so
1235 an XMPP entity can use defined XMPP syntax to interact with the
1236 gateway's presence service. Because PIDF [5] does not specify syntax
1237 for semantic operations such as subscribe, this section defines only
1238 the XMPP interactions with the presence service offered by an
1239 XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
1240 (Note: detailed information about XMPP presence services can be found
1241 in XMPP IM [7]; as much as possible, an XMPP-CPIM gateway SHOULD
1242 implement the syntax, semantics, and server business rules defined
1243 therein.)
1245 5.1 Requesting a Subscription
1247 If an XMPP entity wants to subscribe to the presence information of a
1248 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1249 presence stanza of type "subscribe" to the target presentity. The
1250 syntax mapping is as follows:
1252 o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP
1253 "watcher parameter" field (pres:node@domain). The XMPP-CPIM
1254 gateway MUST append the "pres:" Presence URI scheme to the front
1255 of the address.
1257 o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP
1258 "target parameter" field (pres:node@domain). The XMPP-CPIM gateway
1259 MUST append the "pres:" Presence URI scheme to the front of the
1260 address.
1262 o There is no XMPP mapping for the CPP "duration parameter", since
1263 XMPP subscriptions are active until they have been explicitly
1264 "unsubscribed" (see Subscription Durations (Section 5.3)).
1266 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1267 field.
1269 If the target presentity approves the subscription request (through
1270 whatever protocol it uses to interact with the gateway), the
1271 XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
1272 to the XMPP entity and notify the XMPP entity of the target's current
1273 available presence. Thereafter, until the subscription is cancelled,
1274 the gateway MUST notify the subscribing XMPP entity every time the
1275 target's presence information changes.
1277 If the target presentity denies the subscription request, the
1278 XMPP-CPIM gateway MUST return a presence stanza of type
1279 "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
1280 operation.
1282 In addition to the approval and denial cases, one of the following
1283 exceptions MAY occur:
1285 o The target parameter (XMPP "to" address) does not refer to a valid
1286 presentity; if this exception occurs, the XMPP-CPIM gateway MUST
1287 return an stanza error to the XMPP entity.
1289 o Access control rules do not permit the entity to subscribe to the
1290 target; if this exception occurs, the XMPP-CPIM gateway MUST
1291 return a stanza error to the XMPP entity.
1293 o There exists a pre-existing subscription or in-progress subscribe
1294 operation between the XMPP entity and the target presentity; if
1295 this exception occurs, the XMPP-CPIM gateway SHOULD return a
1296 stanza error to the XMPP entity.
1298 5.2 Receiving a Subscription Request
1300 If a non-XMPP presentity wants to subscribe to the presence
1301 information of an XMPP entity through an XMPP-CPIM gateway, it MUST
1302 use whatever protocol it uses to interact with the gateway in order
1303 to request the subscription; subject to local access rules, the
1304 gateway MUST then send a presence stanza of type "subscribe" to the
1305 XMPP entity from the non-XMPP watcher. The syntax mapping is as
1306 follows:
1308 o The CPP "watcher parameter" field (pres:node@domain) MUST be
1309 mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM
1310 gateway MUST remove the "pres:" Presence URI scheme from the front
1311 of the address.
1313 o The CPP "target parameter" field (pres:node@domain) MUST be mapped
1314 to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway
1315 MUST remove the "pres:" Presence URI scheme from the front of the
1316 address.
1318 o There is no XMPP mapping for the CPP "duration parameter", since
1319 XMPP subscriptions are active until they have been explicitly
1320 "unsubscribed" (see Subscription Durations (Section 5.3)).
1322 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1323 field.
1325 If the target XMPP entity approves the subscription request, it MUST
1326 send a presence stanza of type "subscribed" to the watcher
1327 presentity. The XMPP-CPIM gateway MUST then notify the watcher
1328 presentity of the target XMPP entity's current available presence.
1329 Thereafter, until the subscription is cancelled, the gateway MUST
1330 notify the watcher presentity every time the target's presence
1331 information changes.
1333 If the target XMPP entity denies the subscription request, it MUST
1334 send a presence stanza of type "unsubscribed" to the watcher
1335 presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
1336 operation.
1338 In addition to the approval and denial cases, one of the following
1339 exceptions MAY occur:
1341 o The target parameter (XMPP "to" address) does not refer to a valid
1342 XMPP entity
1344 o Access control rules do not permit the watcher presentity to
1345 subscribe to the target XMPP entity
1347 o There exists a pre-existing subscription or in-progress subscribe
1348 operation between the watcher presentity and the target XMPP
1349 entity
1351 If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
1352 the watcher presentity of failure.
1354 5.3 Subscription Durations
1356 XMPP services assume that a subscription is active until it is
1357 explicitly terminated. With the exception of handling duration
1358 parameters whose value is zero, handling duration parameters will be
1359 highly dependent on the implementation and requirements of the
1360 XMPP-CPIM gateway. Since there are no explicit requirements for
1361 supporting a "duration parameter" specified in either RFC 2778 [9] or
1362 RFC 2779 [1], duration parameter mapping is a local issue that falls
1363 outside the scope of this document.
1365 5.4 The Notify Operation
1367 An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
1368 presence information associated with an XMPP entity or CPP presentity
1369 changes and there are subscribers to that information on the other
1370 side of the gateway. The syntax mapping for presence information
1371 related to a notify operation is defined under Mapping for Presence
1372 (Section 4).
1374 5.5 Unsubscribing
1376 If an XMPP entity wants to unsubscribe from the presence of a
1377 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1378 presence stanza of type "unsubscribe" to the target presentity. The
1379 syntax mapping is as follows:
1381 o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP
1382 "watcher parameter" field (pres:node@domain). The XMPP-CPIM
1383 gateway MUST append the "pres:" Presence URI scheme to the front
1384 of the address.
1386 o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP
1387 "target parameter" field (pres:node@domain). The XMPP-CPIM gateway
1388 MUST append the "pres:" Presence URI scheme to the front of the
1389 address.
1391 o The CPP "duration parameter" MUST be set to zero.
1393 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1394 field.
1396 If the target parameter (XMPP "to" address) does not refer to a valid
1397 presentity, the XMPP-CPIM gateway MUST return an
1398 stanza error to the XMPP entity.
1400 Upon receiving the presence stanza of type "unsubscribe" from the
1401 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1402 notifications to the XMPP entity.
1404 5.6 Cancelling a Subscription
1406 If an XMPP entity wants to cancel a non-XMPP presentity's
1407 subscription to the entity's presence through an XMPP-CPIM gateway,
1408 it MUST send a presence stanza of type "unsubscribed" to the target
1409 presentity. The syntax mapping is as follows:
1411 o The CPP "watcher parameter" field (pres:node@domain) MUST be
1412 mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM
1413 gateway MUST remove the "pres:" Presence URI scheme from the front
1414 of the address.
1416 o The CPP "target parameter" field (pres:node@domain) MUST be mapped
1417 to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway
1418 MUST remove the "pres:" Presence URI scheme from the front of the
1419 address.
1421 o The CPP "duration parameter" MUST be set to zero.
1423 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1424 field.
1426 Upon receiving the presence stanza of type "unsubscribed" from the
1427 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1428 notifications to the watcher presentity.
1430 6. Mapping of Character Encodings
1432 The following rules apply to the mapping of character encodings
1433 (charsets):
1435 1. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1436 other than "us-ascii", "utf-8", or "utf-16".
1438 2. A gateway SHOULD map a "Message/CPIM" object whose charset is
1439 "us-ascii" no matter whether the character encoding negotiated
1440 for the XMPP recipient's XML stream is UTF-8 or UTF-16.
1442 3. A gateway SHOULD map a "Message/CPIM" object whose charset is
1443 "utf-8" if the character encoding negotiated for the XMPP
1444 recipient's XML stream is UTF-8.
1446 4. A gateway SHOULD map a "Message/CPIM" object whose charset is
1447 "utf-16" if the character encoding negotiated for the XMPP
1448 recipient's XML stream is UTF-16.
1450 5. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1451 "utf-8" if the character encoding negotiated for the XMPP
1452 recipient's XML stream is UTF-16.
1454 6. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1455 "utf-16" if the character encoding negotiated for the XMPP
1456 recipient's XML stream is UTF-8.
1458 7. Security Considerations
1460 Detailed security considerations for instant messaging and presence
1461 protocols are given in RFC 2779 [1], specifically in Sections 5.1
1462 through 5.4.
1464 This document specifies methods for exchanging instant messages and
1465 presence information through a gateway that implements CPIM [2] and
1466 CPP [3]. Such a gateway MUST be compliant with the minimum security
1467 requirements of the instant messaging and presence protocols with
1468 which it interfaces. The introduction of gateways to the security
1469 model of instant messaging and presence in RFC 2779 also introduces
1470 some new risks. In particular, end-to-end security properties
1471 (especially confidentiality and integrity) between instant messaging
1472 and presence user agents that interface through an XMPP-CPIM gateway
1473 can be provided only if common formats are supported; these formats
1474 are specified fully in End-to-End Object Encryption in XMPP [8].
1476 Normative References
1478 [1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
1479 Presence Protocol Requirements", RFC 2779, February 2000.
1481 [2] Crocker, D. and J. Peterson, "Common Profile for Instant
1482 Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress),
1483 March 2003.
1485 [3] Crocker, D. and J. Peterson, "Common Profile for Presence
1486 (CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003.
1488 [4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
1489 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
1490 progress), January 2003.
1492 [5] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and
1493 J. Peterson, "CPIM Presence Information Data Format",
1494 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
1496 [6] Saint-Andre, P. and J. Miller, "XMPP Core",
1497 draft-ietf-xmpp-core-13 (work in progress), June 2003.
1499 [7] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
1500 draft-ietf-xmpp-im-12 (work in progress), June 2003.
1502 [8] Saint-Andre, P., "End-to-End Object Encryption in XMPP",
1503 draft-ietf-xmpp-e2e-03 (work in progress), May 2003.
1505 [9] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
1506 Instant Messaging", RFC 2778, February 2000, .
1509 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1510 Levels", BCP 14, RFC 2119, March 1997.
1512 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1513 Extensions (MIME) Part One: Format of Internet Message Bodies",
1514 RFC 2045, November 1996.
1516 Informative References
1518 [12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
1520 [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1521 Extensions (MIME) Part Two: Media Types", RFC 2046, November
1522 1996.
1524 Authors' Addresses
1526 Peter Saint-Andre
1527 Jabber Software Foundation
1529 EMail: stpeter@jabber.org
1531 Tony Bamonti
1532 Jabber, Inc.
1534 EMail: tbamonti@jabber.com
1536 Intellectual Property Statement
1538 The IETF takes no position regarding the validity or scope of any
1539 intellectual property or other rights that might be claimed to
1540 pertain to the implementation or use of the technology described in
1541 this document or the extent to which any license under such rights
1542 might or might not be available; neither does it represent that it
1543 has made any effort to identify any such rights. Information on the
1544 IETF's procedures with respect to rights in standards-track and
1545 standards-related documentation can be found in BCP-11. Copies of
1546 claims of rights made available for publication and any assurances of
1547 licenses to be made available, or the result of an attempt made to
1548 obtain a general license or permission for the use of such
1549 proprietary rights by implementors or users of this specification can
1550 be obtained from the IETF Secretariat.
1552 The IETF invites any interested party to bring to its attention any
1553 copyrights, patents or patent applications, or other proprietary
1554 rights which may cover technology that may be required to practice
1555 this standard. Please address the information to the IETF Executive
1556 Director.
1558 Full Copyright Statement
1560 Copyright (C) The Internet Society (2003). All Rights Reserved.
1562 This document and translations of it may be copied and furnished to
1563 others, and derivative works that comment on or otherwise explain it
1564 or assist in its implementation may be prepared, copied, published
1565 and distributed, in whole or in part, without restriction of any
1566 kind, provided that the above copyright notice and this paragraph are
1567 included on all such copies and derivative works. However, this
1568 document itself may not be modified in any way, such as by removing
1569 the copyright notice or references to the Internet Society or other
1570 Internet organizations, except as needed for the purpose of
1571 developing Internet standards in which case the procedures for
1572 copyrights defined in the Internet Standards process must be
1573 followed, or as required to translate it into languages other than
1574 English.
1576 The limited permissions granted above are perpetual and will not be
1577 revoked by the Internet Society or its successors or assignees.
1579 This document and the information contained herein is provided on an
1580 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1581 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1582 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1583 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1584 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1586 Acknowledgement
1588 Funding for the RFC Editor function is currently provided by the
1589 Internet Society.