idnits 2.17.1
draft-ietf-xmpp-cpim-02.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 (August 22, 2003) is 7552 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-17
== Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-16
== Outdated reference: A later version (-09) exists of
draft-ietf-xmpp-e2e-04
** 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: February 20, 2004 T. Bamonti
5 Jabber, Inc.
6 August 22, 2003
8 XMPP CPIM Mapping
9 draft-ietf-xmpp-cpim-02
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 February 20, 2004.
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 Message 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 Message Syntax Mapping from CPIM Specifications to XMPP . 11
70 3.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 11
71 3.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 Presence 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 . . . . . . . . . . . . . . . . . . . . 21
99 4.2.16 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 22
100 4.2.17 XMPP Presence Extensions . . . . . . . . . . . . . . . . . 22
101 4.3 Presence Syntax Mapping from CPIM Specifications to XMPP . 22
102 4.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 22
103 4.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 23
104 4.3.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 23
105 4.3.4 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . 24
110 4.3.9 PIDF MIME Content-ID . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 26
114 4.3.13 PIDF Contact Element . . . . . . . . . . . . . . . . . . . 27
115 4.3.14 Presence Priority . . . . . . . . . . . . . . . . . . . . 28
116 4.3.15 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 28
117 5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . 29
118 5.1 Requesting a Subscription . . . . . . . . . . . . . . . . 29
119 5.2 Receiving a Subscription Request . . . . . . . . . . . . . 30
120 5.3 Subscription Durations . . . . . . . . . . . . . . . . . . 31
121 5.4 The Notify Operation . . . . . . . . . . . . . . . . . . . 31
122 5.4.1 Multiple Resources . . . . . . . . . . . . . . . . . . . . 32
123 5.4.2 Zero Resources . . . . . . . . . . . . . . . . . . . . . . 32
124 5.5 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 33
125 5.6 Cancelling a Subscription . . . . . . . . . . . . . . . . 33
126 6. Mapping of Character Encodings . . . . . . . . . . . . . . 35
127 7. Security Considerations . . . . . . . . . . . . . . . . . 36
128 Normative References . . . . . . . . . . . . . . . . . . . 37
129 Informative References . . . . . . . . . . . . . . . . . . 38
130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
131 A. Revision History . . . . . . . . . . . . . . . . . . . . . 39
132 A.1 Changes from draft-ietf-xmpp-cpim-01 . . . . . . . . . . . 39
133 A.2 Changes from draft-ietf-xmpp-cpim-00 . . . . . . . . . . . 39
134 Intellectual Property and Copyright Statements . . . . . . 40
136 1. Introduction
138 1.1 Overview
140 The Instant Messaging and Presence (IMPP) Working Group has defined
141 an abstract framework for interoperability among instant messaging
142 (IM) and presence systems that are compliant with RFC 2779 [1]. This
143 framework is commonly called Common Presence and Instant Messaging or
144 "CPIM". The CPIM specifications include a Common Profile for Instant
145 Messaging [2] (also called CPIM), a Common Profile for Presence [3]
146 (CPP), a CPIM Message Format [4] (MSGFMT), and a Common Presence
147 Information Data Format [5] (PIDF). (Note: to prevent confusion,
148 Common Presence and Instant Messaging is referred to herein
149 collectively as "the CPIM specifications", whereas the Common Profile
150 for Instant Messaging is referred to as "CPIM". However, the term
151 "XMPP-CPIM Gateway" is used to refer to a gateway between an XMPP
152 service and a non-XMPP service, where the common format is defined by
153 the CPIM specifications.)
155 This document describes how the Extensible Messaging and Presence
156 Protocol (XMPP Core [6], XMPP IM [7]) maps to the abstract model
157 contained in the CPIM specifications, mainly for the purpose of
158 establishing gateways between XMPP services and non-XMPP services
159 that conform to RFC 2779 [1]. Such gateways may be established to
160 interpret the protocols of one service and translate them into the
161 protocols of the other service. We can visualize this relationship as
162 follows:
164 +-------------+ +-------------+ +------------+
165 | | | | | |
166 | XMPP | | XMPP-CPIM | | Non-XMPP |
167 | Service | <----> | Gateway | <----> | Service |
168 | | | | | |
169 +-------------+ +-------------+ +------------+
171 This document defines a mapping for use by a gateway that translates
172 between XMPP and a non-XMPP protocol via the CPIM specifications.
173 Such a gateway is not an intermediate hop on a network of non-XMPP
174 servers (whose native formats may or may not be defined by the CPIM
175 specifications), but a dedicated translator between XMPP and a
176 non-XMPP protocol, where the CPIM specifications define the common
177 formats into which the protocols are translated for purposes of
178 interworking.
180 The mapping defined herein applies to instant messages and presence
181 information that are not encrypted or signed for end-to-end security.
182 For information about secure communications to or from an XMPP
183 service through an XMPP-CPIM gateway, refer to End-to-End Object
184 Encryption in XMPP [8].
186 1.2 Terminology
188 This memo inherits vocabulary defined in RFC 2778 [9]. Terms such as
189 CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
190 PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
191 defined therein.
193 This memo also inherits vocabulary defined in XMPP Core [6]. Terms
194 such as ENTITY, JID, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
195 IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
196 meaning as defined therein.
198 1.3 Conventions Used in this Document
200 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
201 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
202 "OPTIONAL" in this document are to be interpreted as described in RFC
203 2119 [10].
205 1.4 Discussion Venue
207 The authors welcome discussion and comments related to the topics
208 presented in this document. The preferred forum is the
209 mailing list, for which archives and subscription
210 information are available at .
213 1.5 Intellectual Property Notice
215 This document is in full compliance with all provisions of Section 10
216 of RFC 2026. Parts of this specification use the term "jabber" for
217 identifying namespaces and other protocol syntax. Jabber[tm] is a
218 registered trademark of Jabber, Inc. Jabber, Inc. grants permission
219 to the IETF for use of the Jabber trademark in association with this
220 specification and its successors, if any.
222 2. Approach
224 XMPP and CPIM are distinctly foreign technologies. Therefore, care
225 must be taken in mapping between XMPP and the abstract syntax defined
226 by the CPIM specifications.
228 At root, XMPP is a data transport protocol for streaming XML
229 fragments (called "stanzas") between any two endpoints on the
230 network; message and presence stanzas are two of the core data
231 elements defined in XMPP and are often used to exchange instant
232 messages and presence information between IM users (although the
233 inherent extensibility of XML enables applications to use the general
234 semantics of these stanza types for other purposes). XMPP is not
235 based on MIME [11]; instead, XMPP Core [6] defines XML schemas for
236 both message and presence stanzas (for example, the child of
237 a message stanza contains XML character data that is usually intended
238 to be read by a human user).
240 The CPIM specifications provide common formats for instant messaging
241 and presence through two MIME [11] content-types: "Message/CPIM" for
242 messages (MSGFMT [4]) and "application/pidf+xml" for presence (PIDF
243 [5]). The syntax of "Message/CPIM" objects is similar to but stricter
244 than that of RFC 2822 [12], and includes the ability to include
245 arbitrary MIME media types [13]. By contrast, each "application/
246 pidf+xml" object is a complete XML document whose structure is
247 defined by an XML schema.
249 The approach taken herein is to specify mappings from XMPP elements
250 and attributes to the headers and MIME formats defined by MSGFMT [4]
251 and PIDF [5] in order to comply with the semantics defined by CPIM
252 [2] and CPP [3]. Naturally, mappings in the opposite direction are
253 provided as well.
255 3. Mapping of Instant Messages
257 This section describes how a gateway SHOULD map instant messages
258 between an XMPP service and a non-XMPP service using a "Message/CPIM"
259 object as the bearer of encapsulated text content in order to comply
260 with the instant messaging semantics defined by CPIM [2].
262 3.1 Identification of Instant Inboxes
264 There is a one-to-one relationship between an XMPP entity and a CPIM
265 instant inbox when the JID of the entity contains only a node
266 identifier and domain identifier, and the node identifier uniquely
267 corresponds to an IM user who possesses an account on an XMPP server.
268 However, the syntax for addressing an instant inbox is specified as
269 including the 'im:' URI scheme, whereas an XMPP address does not
270 include that scheme, so any mapping between an instant inbox address
271 and a JID must add or remove the 'im:' URI scheme as appropriate.
273 3.2 Message Syntax Mapping from XMPP to CPIM Specifications
275 This section defines the mapping of syntax primitives from XMPP
276 message stanzas to "Message/CPIM" objects with encapsulated text
277 content.
279 3.2.1 From Address
281 The 'from' attribute of an XMPP message stanza maps to the 'From'
282 header of a "Message/CPIM" object. In XMPP, the sender MUST NOT
283 include a 'from' attribute; instead, the sender's server stamps the
284 "from" address and sets its value to the full authzid (including
285 resource identifier) provided by the client when authenticating. Thus
286 an XMPP-CPIM gateway will receive from the sender's XMPP server a
287 message stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP message stanza to
289 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
290 the resource identifier, MUST append the "im:" Instant Messaging URI
291 scheme to the front of the address, and MAY include a CPIM
292 "Formal-name" for the sender (if known).
294 Example: From Address Mapping
296 XMPP 'from' attribute
297
298 ...
299
301 CPIM 'From' header
302 From: Juliet Capulet
304 3.2.2 To Address
306 The 'to' attribute of an XMPP message stanza maps to the 'To' header
307 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 'to'
308 attribute on a message stanza, and MUST include it if the message is
309 intended for delivery to another user. Thus an XMPP-CPIM gateway will
310 receive from the sender's XMPP server a message stanza containing a
311 "to" address of the form or . To
312 map the 'to' attribute of an XMPP message stanza to the 'To' header
313 of a "Message/CPIM" object, the gateway MUST remove the resource
314 identifier (if included), MUST append the "im:" Instant Messaging URI
315 scheme to the front of the address, and MAY include a CPIM
316 "Formal-name" for the recipient (if known).
318 Example: To Address Mapping
320 XMPP 'to' attribute
321
322 ...
323
325 CPIM 'To' header
326 To: Romeo Montague
328 3.2.3 CPIM Courtesy Copy
330 The core XMPP specification does not include syntax for specifying a
331 "courtesy copy" (non-primary addressee) for a message stanza.
332 Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of
333 a "Message/CPIM" object.
335 3.2.4 XMPP Stanza ID
337 An XMPP message stanza MAY possess an 'id' attribute, which is used
338 by the sending application for the purpose of tracking stanzas. There
339 is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header,
340 common MIME features, or encapsulated text content. Therefore if an
341 XMPP stanza received by an XMPP-CPIM gateway possesses an 'id'
342 attribute, the gateway SHOULD ignore the value provided.
344 3.2.5 XMPP Message Type
346 An XMPP message stanza MAY possess a 'type' attribute, which is used
347 by the sending application to capture the conversational context of
348 the message. There is no mapping of an XMPP 'type' attribute to a
349 "Message/CPIM" header, common MIME features, or encapsulated text
350 content. Therefore if an XMPP stanza received by an XMPP-CPIM gateway
351 possesses a 'type' attribute, the gateway SHOULD ignore the value
352 provided.
354 3.2.6 XMPP Message Thread
356 An XMPP message stanza MAY contain a child element to
357 specify the conversation thread in which the message is situated.
358 There is no mapping of an XMPP element to a "Message/CPIM"
359 header, common MIME features, or encapsulated text content. Therefore
360 if an XMPP message stanza received by an XMPP-CPIM gateway contains a
361 child element, the gateway SHOULD ignore the value
362 provided.
364 3.2.7 CPIM DateTime Header
366 The core XMPP specification does not include syntax for specifying
367 the datetime at which a message stanza was sent. However, an
368 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
369 CPIM" object it generates, the value of which SHOULD be the datetime
370 at which the message stanza was received for processing by the
371 gateway.
373 3.2.8 Message Subject
375 An XMPP message stanza MAY include a child element. If
376 included, it maps to the 'Subject' header of a "Message/CPIM" object.
377 The element MAY include an 'xml:lang' attribute specifying
378 the language in which the subject is written. To map the XMPP
379 element to the 'Subject' header of a "Message/CPIM"
380 object, the gateway SHOULD simply map the XMPP CDATA to the value of
381 the 'Subject' header. If an 'xml:lang' attribute is provided, it MUST
382 be mapped by including ';lang=tag' after the header name and colon,
383 where 'tag' is the value of the 'xml:lang' attribute.
385 Example: Subject Mapping
387 XMPP element
388 Hi!
389 Ahoj!
391 CPIM 'Subject' header
392 Subject: Hi!
393 Subject:;lang=cz Ahoj!
395 3.2.9 CPIM Header Extensions
397 A "Message/CPIM" object MAY include an optional 'NS' header to
398 specify the namespace of a feature extension. An XMPP-CPIM gateway
399 SHOULD NOT generate such headers.
401 3.2.10 CPIM Required Headers
403 A "Message/CPIM" object MAY include an optional 'Required' header to
404 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
405 NOT generate such headers.
407 3.2.11 MSGFMT MIME Content-type
409 RFC 2045 [11] specifies that the default Content-type of a MIME
410 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
411 uses a different character encoding (either UTF-8 or UTF-16 depending
412 on stream negotiation), the encapsulated MIME object generated by an
413 XMPP-CPIM gateway MUST set the 'Content-type' header for that object.
414 The "Content-type" MUST be set to "text/plain" and the charset MUST
415 be set to the character encoding negotiated for the XML stream used
416 by the sender, i.e., either UTF-8 or UTF-16.
418 Example: Content-type for Encapsulated Object
420 Content-type: text/plain; charset=utf-8
422 3.2.12 MSGFMT MIME Content-ID
424 RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME
425 objects. While an XMPP-CPIM gateway MAY generate a Content-ID for
426 encapsulated MIME objects, it is NOT REQUIRED to do so. If included,
427 Content-ID values MUST be generated to be world-unique.
429 Example: Content-ID for Encapsulated Object
431 Content-ID: <123456789@montague.net>
433 3.2.13 Message Body
435 The child element of an XMPP message stanza is used to
436 provide the primary meaning of the message. The CDATA of the XMPP
437 element maps to the encapsulated text message content.
439 Example: Message Body
441 XMPP message
442
443 Wherefore art thou, Romeo?
445
447 Encapsulated MIME text content
448 Content-type: text/plain; charset=utf-8
449 Content-ID: <123456789@montague.net>
451 Wherefore art thou, Romeo?
453 3.2.14 XMPP Message Extensions
455 As defined in XMPP Core [6], an XMPP message stanza may contain
456 "extended" content in any namespace in order to supplement or extend
457 the semantics of the core message stanza. With the exception of
458 extended information qualified by the
459 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End
460 Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore
461 such information and not pass it through the gateway to the intended
462 recipient. No mapping for such information is defined.
464 3.3 Message Syntax Mapping from CPIM Specifications to XMPP
466 This section defines the mapping of syntax primitives from "Message/
467 CPIM" objects with encapsualted text content to XMPP message stanzas.
469 3.3.1 From Address
471 The 'From' header of a "Message/CPIM" object maps to the 'from'
472 attribute of an XMPP message stanza. To map the CPIM 'From' header to
473 the XMPP 'from' attribute, the gateway MUST remove the "im:" Instant
474 Messaging URI scheme from the front of the address and MUST remove
475 the CPIM "Formal-name" (if provided).
477 Example: From Address Mapping
479 CPIM 'From' header
480 From: Romeo Montague
482 XMPP 'from' attribute
483
484 ...
485
487 3.3.2 To Address
489 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
490 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP
491 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
492 URI scheme from the front of the address and MUST remove the CPIM
493 "Formal-name" (if provided). If the gateway possesses knowledge of
494 the resource identifier in use by the XMPP entity, the gateway MAY
495 append the resource identifier to the address.
497 Example: To Address Mapping
499 CPIM 'To' header
500 To: Juliet Capulet
502 XMPP 'to' attribute
503
504 ...
505
507 3.3.3 CPIM Courtesy Copy
509 The core XMPP specification does not include syntax for specifying a
510 "courtesy copy" (non-primary addressee) for a message stanza.
511 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
512 that contains a 'cc' header, it MUST NOT pass that information on to
513 the XMPP recipient.
515 3.3.4 XMPP Message Type
517 MSGFMT does not possess the concept of a message type that can map to
518 the XMPP 'type' attribute for message stanzas. Therefore an XMPP-CPIM
519 gateway SHOULD NOT include the 'type' attribute on the messages it
520 sends to XMPP recipients.
522 3.3.5 CPIM DateTime Header
524 The core XMPP specification does not include syntax for specifying
525 the datetime at which a message stanza was sent. Therefore, if an
526 XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
527 'DateTime' header, it SHOULD NOT pass that information on to the XMPP
528 recipient.
530 3.3.6 Message Subject
532 The 'Subject' header of a "Message/CPIM" object maps to the child element of an XMPP message stanza. The 'Subject' header MAY
534 specify the "lang" in which the subject is written. To map the CPIM
535 'Subject' header to the XMPP element, the gateway SHOULD
536 simply map the value of the 'Subject' header to the XMPP CDATA. If
537 "lang" information is provided, it MUST be mapped to the 'xml:lang'
538 attribute of the element, where the value of the
539 'xml:lang' attribute is the the "tag" value supplied in the string
540 ';lang=tag' included CPIM 'Subject' header name and colon.
542 Example: Subject Mapping
544 CPIM 'Subject' header
545 Subject: Hi!
546 Subject:;lang=cz Ahoj!
548 XMPP element
549 Hi!
550 Ahoj!
552 3.3.7 CPIM Header Extensions
554 "Message/CPIM" objects MAY include an optional 'NS' header to specify
555 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
556 pass such headers through to the XMPP recipient, and no mapping for
557 such headers is defined.
559 3.3.8 CPIM Required Headers
561 "Message/CPIM" objects MAY include an optional 'Required' header to
562 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
563 NOT pass such headers through to the XMPP recipient, and no mapping
564 for such headers is defined.
566 3.3.9 MSGFMT MIME Content-type
568 CPIM [4] specifies that a "Message/CPIM" object MAY contain any
569 arbitrary MIME content. However, support for arbitrary content types
570 is not a requirement in XMPP; in particular, the child
571 element of an XMPP message stanza MUST contain XML character data
572 only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP message
573 stanza a "Message/CPIM" object whose encapsulated MIME object has a
574 Content-type other than "text/plain" (with the exception of
575 multi-part MIME objects used for End-to-End Object Encryption in XMPP
576 [8]).
578 3.3.10 MSGFMT MIME Content-ID
580 XMPP does not include an element or attribute that captures a
581 globally unique ID as is defined for the Content-ID MIME header as
582 specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME
583 object that includes a Content-ID, it MAY provide the Content-ID as
584 the value of the message stanza's 'id' attribute but is NOT REQUIRED
585 to do so.
587 Example: Content-ID for Encapsulated Object
589 MIME header
590 Content-ID: <123456789@montague.net>
592 XMPP 'id' attribute (OPTIONAL)
593
594 ...
595
597 3.3.11 Message Body
599 If the Content-type of an encapsulated MIME object is "text/plain",
600 then the encapsulated text message content maps to the CDATA of the
601 child element of an XMPP message stanza.
603 Example: Message Body
605 Encapsulated MIME text content
606 Content-type: text/plain; charset=utf-8
607 Content-ID: <123456789@montague.net>
609 Wherefore art thou?
611 XMPP message
612
613 Wherefore art thou?
614
616 4. Mapping of Presence
618 This section describes how a gateway SHOULD map presence information
619 between an XMPP service and a non-XMPP service using a "Message/CPIM"
620 object as the bearer of an encapsulated PIDF [5] object in order to
621 comply with the presence semantics defined by CPP [3].
623 4.1 Identification of Presentities
625 There is a one-to-one relationship between an XMPP entity and a CPP
626 presentity when the JID of the entity contains only a node identifier
627 and domain identifier, and the node identifier uniquely corresponds
628 to an IM user who possesses an account on an XMPP server. However,
629 the syntax of presentities is specified as including the 'pres:' URI
630 scheme, whereas XMPP addresses do not include that scheme, so any
631 mapping between presentities and JIDs must add or remove the 'pres:'
632 URI scheme as appropriate.
634 4.2 Presence Syntax Mapping from XMPP to CPIM Specifications
636 This section defines the mapping of syntax primitives from XMPP
637 presence stanzas to "Message/CPIM" objects with encapsulated
638 "application/pidf+xml" objects.
640 4.2.1 From Address
642 The 'from' attribute of an XMPP presence stanza maps to the 'From'
643 header of a "Message/CPIM" object. In XMPP, the sender MUST NOT
644 include a 'from' attribute; instead, the sender's server stamps the
645 "from" address and sets its value to the full authzid (including
646 resource identifier) provided by the client when authenticating. Thus
647 an XMPP-CPIM gateway will receive from the sender's XMPP server a
648 presence stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP presence stanza to
650 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
651 the resource identifier, MUST append the "im:" Instant Messaging URI
652 scheme to the front of the address, and MAY include a CPIM
653 "Formal-name" for the sender (if known).
655 Example: From Address Mapping
657 XMPP 'from' attribute
658
659 ...
660
662 CPIM 'From' header
663 From: Juliet Capulet
665 In addition, the 'from' attribute of an XMPP presence stanza maps to
666 the 'entity' attribute of a PIDF root element. To map the
667 XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
668 MUST remove the resource identifier and MUST append the "pres:"
669 Instant Messaging URI scheme to the front of the address.
671 Example: From Address Mapping (PIDF)
673 XMPP 'from' attribute
674
675 ...
676
678 PIDF 'entity' attribute
679
680 ...
681
683 Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
684 the JID contained in the XMPP 'from' attribute to the 'id' attribute
685 of the PIDF child element.
687 Example: Resource Identifier Mapping
689 XMPP 'from' attribute
690
691 ...
692
694 PIDF 'id' for
695
696
697 ...
698
699
701 4.2.2 To Address
703 The 'to' attribute of an XMPP presence stanza maps to the 'To' header
704 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 'to'
705 attribute on a presence stanza, and MUST include it if the presence
706 is intended for delivery to another user. Thus an XMPP-CPIM gateway
707 will receive from the sender's XMPP server a presence stanza
708 containing a "to" address of the form or . To map the 'to' attribute of an XMPP presence stanza to
710 the 'To' header of a "Message/CPIM" object, the gateway MUST remove
711 the resource identifier (if included), MUST append the "im:" Instant
712 Messaging URI scheme to the front of the address, and MAY include a
713 CPIM "Formal-name" for the recipient (if known).
715 Example: To Address Mapping
717 XMPP 'to' attribute
718
719 ...
720
722 CPIM 'To' header
723 To: Romeo Montague
725 4.2.3 CPIM Courtesy Copy
727 The core XMPP specification does not include syntax for specifying a
728 "courtesy copy" (non-primary addressee) for a presence stanza.
729 Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of
730 a "Message/CPIM" object.
732 4.2.4 XMPP Stanza ID
734 An XMPP presence stanza MAY possess an 'id' attribute, which is used
735 by the sending application for the purpose of tracking stanzas. There
736 is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header,
737 common MIME features, or PIDF elements and attributes. Therefore if
738 an XMPP stanza received by an XMPP-CPIM gateway possesses an 'id'
739 attribute, the gateway SHOULD ignore the value provided.
741 4.2.5 CPIM DateTime Header
743 The core XMPP specification does not include syntax for specifying
744 the datetime at which a presence stanza was sent. However, an
745 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
746 CPIM" object it generates, the value of which SHOULD be the datetime
747 at which the presence stanza was received for processing by the
748 gateway.
750 4.2.6 CPIM Subject Header
752 An XMPP presence stanza contains no information that can be mapped to
753 the 'Subject' header of a "Message/CPIM" object. Therefore an
754 XMPP-CPIM gateway SHOULD NOT generate such headers when mapping XMPP
755 presence stanzas.
757 4.2.7 CPIM Header Extensions
758 A "Message/CPIM" object MAY include an optional 'NS' header to
759 specify the namespace of a feature extension. An XMPP-CPIM gateway
760 SHOULD NOT generate such headers.
762 4.2.8 CPIM Required Headers
764 A "Message/CPIM" object MAY include an optional 'Required' header to
765 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
766 NOT generate such headers.
768 4.2.9 PIDF MIME Content-type
770 RFC 2045 [11] specifies that the default Content-type of a MIME
771 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
772 uses a different character encoding (either UTF-8 or UTF-16 depending
773 on stream negotiation) and because PIDF specifies the "application/
774 pidf+xml" MIME time, the encapsulated MIME object generated by an
775 XMPP-CPIM gateway for presence information MUST set the
776 'Content-type' header for that object. The "Content-type" MUST be set
777 to "application/pidf+xml" and the charset MUST be set to the
778 character encoding negotiated for the XML stream used by the sender,
779 i.e., either UTF-8 or UTF-16.
781 Example: Content-type for Encapsulated PIDF Object
783 Content-type: application/pidf+xml; charset=utf-8
785 4.2.10 PIDF MIME Content-ID
787 RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME
788 objects. While an XMPP-CPIM gateway MAY generate a Content-ID for
789 encapsulated MIME objects, it is NOT REQUIRED to do so. If included,
790 Content-ID values MUST be generated to be world-unique.
792 Example: Content-ID for Encapsulated Object
794 Content-ID: <123456789@montague.net>
796 4.2.11 XMPP Presence Type
798 An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
799 attribute is included, the presence stanza indicates that the sender
800 is available; this state maps to the PIDF basic presence type of
801 OPEN. If the 'type' attribute has a value of "unavailable", the
802 presence stanza indicates that the sender is no longer available;
803 this state maps to the PIDF basic presence type of CLOSED. Thus both
804 the absence of a 'type' attribute and a 'type' attribute set to a
805 value of "unavailable" correspond to the CPP [3] "notify operation".
806 All other presence types are used to manage presence subscriptions or
807 probe for current presence; mappings for these other presence types
808 are defined under XMPP-CPIM Gateway as Presence Service (Section 5).
810 Example: Available Presence
812 XMPP available presence
813
815 PIDF basic presence (OPEN)
816
817
819
820
821 open
822
823
824
826 Example: Unavailable Presence
828 XMPP unavailable presence
829
831 PIDF basic presence (CLOSED)
832
833
835
836
837 closed
838
839
840
842 4.2.12 XMPP Show Element
844 The child element of an XMPP presence stanza provides
845 additional information about the sender's availability. The CDATA of
846 the XMPP element maps to extended content in PIDF.
847 The defined values of the element are 'away', 'chat', 'dnd',
848 and 'xa'; as soon as values are specified for extended status states
849 in the 'urn:ietf:params:xml:ns:pidf:im' namespace, the XMPP values
850 will be mapped to the PIDF values.
852 Example: Show Element
854 XMPP element
855
856 away
857
859 PIDF extended presence information
860
861
864
865
866 open
867 away
868
869
870
872 4.2.13 XMPP Status Element
874 The child element of an XMPP presence stanza provides a
875 user-defined, natural-language description of the sender's detailed
876 availability state. The XMPP element maps to the PIDF
877 child of the PIDF element.
879 Example: Status Element
881 XMPP element
882
883 away
884 retired to the chamber
885
887 PIDF element
888
889
892
893
894 open
895 away
896
897 retired to the chamber
898
900
902 4.2.14 PIDF Contact Element
904 The core XMPP specification does not include syntax for specifying
905 the URL of a contact address, since the contact address is implicit
906 in the 'from' attribute of the XMPP presence stanza. However, an
907 XMPP-CPIM gateway MAY include the child of the
908 element, the value of which SHOULD be the bare JID () of
909 the XMPP sender, prepended by the "im:" Instant Messaging URI scheme.
911 Example: PIDF Contact Element
913 XMPP presence stanza
914
916 PIDF element
917
918
920
921 ...
922 im:juliet@capulet.com
923
924
926 4.2.15 Presence Priority
928 An XMPP presence stanza MAY contain a child element whose
929 value is an integer between -128 and +127. The value of this element
930 MAY be mapped to the 'priority' attribute of the child of
931 the PIDF element. If the value of the XMPP
932 element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
933 range of allowable values for the PIDF 'priority' attribute is any
934 decimal number from zero to one inclusive, with a maximum of three
935 decimal places. If an XMPP-CPIM gateway maps these values, it SHOULD
936 treat XMPP 0 as PIDF priority='0' and XMPP
937 127 as PIDF priority='1', mapping intermediate
938 values appropriately so that they are unique (e.g., XMPP priority 1
939 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
940 so on up through mapping XMPP priority 126 to PIDF priority 0.992;
941 note that this is an example only, and that the exact mapping shall
942 be determined by the XMPP-CPIM gateway).
944 Example: Presence Priority
945 XMPP element
946
947 13
948
950 PIDF element
951
952
954
955 ...
956 im:juliet@capulet.com
957
958
960 4.2.16 PIDF Timestamp Element
962 The core XMPP specification does not include syntax for specifying
963 the datetime at which a presence stanza was sent. However, an
964 XMPP-CPIM gateway MAY include a element within the PIDF
965 document it generates, the value of which SHOULD be the datetime at
966 which the presence stanza was received for processing by the gateway.
968 4.2.17 XMPP Presence Extensions
970 As defined in XMPP Core [6], an XMPP presence stanza may contain
971 "extended" content in any namespace in order to supplement or extend
972 the semantics of the core presence stanza. With the exception of
973 extended information qualified by the
974 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End
975 Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore
976 such information and not pass it through the gateway to the intended
977 recipient. No mapping for such information is defined.
979 4.3 Presence Syntax Mapping from CPIM Specifications to XMPP
981 This section defines the mapping of syntax primitives from "Message/
982 CPIM" objects with encapsulated "application/pidf+xml" objects to
983 XMPP presence stanzas.
985 4.3.1 From Address
987 The 'From' header of a "Message/CPIM" object maps to the 'from'
988 attribute of an XMPP presence stanza. To map the CPIM 'From' header
989 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
990 Instant Messaging URI scheme from the front of the address and MUST
991 remove the CPIM "Formal-name" (if provided).
993 Example: From Address Mapping
995 CPIM 'From' header
996 From: Romeo Montague
998 XMPP 'from' attribute
999
1000 ...
1001
1003 4.3.2 To Address
1005 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
1006 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
1007 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
1008 URI scheme from the front of the address and MUST remove the CPIM
1009 "Formal-name" (if provided). If the gateway possesses knowledge of
1010 the resource identifier in use by the XMPP entity, the gateway MAY
1011 append the resource identifier to the address.
1013 Example: To Address Mapping
1015 CPIM 'To' header
1016 To: Juliet Capulet
1018 XMPP 'to' attribute
1019
1020 ...
1021
1023 4.3.3 CPIM Courtesy Copy
1025 The core XMPP specification does not include syntax for specifying a
1026 "courtesy copy" (non-primary addressee) for a presence stanza.
1027 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1028 with encapsulated PIDF object that contains a 'cc' header, it MUST
1029 NOT pass that information on to the XMPP recipient.
1031 4.3.4 CPIM DateTime Header
1033 The core XMPP specification does not include syntax for specifying
1034 the datetime at which a presence stanza was sent. Therefore, if an
1035 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1036 PIDF object that contains a 'DateTime' header, it SHOULD NOT pass
1037 that information on to the XMPP recipient.
1039 4.3.5 CPIM Subject Header
1041 An XMPP presence stanza contains no information that can be mapped to
1042 the 'Subject' header of a "Message/CPIM" object. Therefore, if an
1043 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1044 PIDF object that contains a 'Subject' header, it SHOULD NOT pass that
1045 information on to the XMPP recipient.
1047 4.3.6 CPIM Header Extensions
1049 "Message/CPIM" objects MAY include an optional 'NS' header to specify
1050 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
1051 pass such headers through to the XMPP recipient, and no mapping for
1052 such headers is defined.
1054 4.3.7 CPIM Required Headers
1056 "Message/CPIM" objects MAY include an optional 'Required' header to
1057 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
1058 NOT pass such headers through to the XMPP recipient, and no mapping
1059 for such headers is defined.
1061 4.3.8 PIDF MIME Content-type
1063 CPIM [4] specifies that a "Message/CPIM" object MAY contain any
1064 arbitrary MIME content. However, support for arbitrary content types
1065 is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to an
1066 XMPP presence stanza a "Message/CPIM" object whose encapsulated MIME
1067 object has a Content-type other than "application/pidf+xml" (with the
1068 exception of multi-part MIME objects used for End-to-End Object
1069 Encryption in XMPP [8]).
1071 4.3.9 PIDF MIME Content-ID
1073 XMPP does not include an element or attribute that captures a
1074 globally unique ID as is defined for the Content-ID MIME header as
1075 specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME
1076 object that includes a Content-ID, it MAY provide the Content-ID as
1077 the value of the presence stanza's 'id' attribute but is NOT REQUIRED
1078 to do so.
1080 Example: Content-ID for Encapsulated Object
1082 MIME header
1083 Content-ID: <123456789@montague.net>
1085 XMPP 'id' attribute (OPTIONAL)
1086
1087 ...
1088
1090 4.3.10 PIDF Basic Presence Status
1092 The basic presence status types defined in PIDF are OPEN and CLOSED.
1093 The PIDF basic presence status of OPEN maps to an XMPP presence
1094 stanza that possesses no 'type' attribute (indicating default
1095 availability). The PIDF basic presence status of CLOSED maps to an
1096 XMPP presence stanza that possesses a 'type' attribute with a value
1097 of "unavailable".
1099 Example: OPEN Presence
1101 PIDF basic presence (OPEN)
1102
1103
1105
1106
1107 open
1108
1109
1110
1112 XMPP available presence
1113
1115 Example: CLOSED Presence
1117 PIDF basic presence (CLOSED)
1118
1119
1121
1122
1123 closed
1124
1125
1126
1128 XMPP unavailable presence
1129
1132 4.3.11 PIDF Extended Status Information
1134 PIDF documents may contain extended content. As of this
1135 writing there are no pre-defined extended status states that
1136 correspond to the defined values of the XMPP element ('away',
1137 'chat', 'dnd', and 'xa'); as soon as values are specified for
1138 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
1139 namespace, the PIDF values will be mapped to the relevant XMPP
1140 values.
1142 Example: Extended Status Information (provisional)
1144 PIDF extended presence information
1145
1146
1149
1150
1151 open
1152 busy
1153
1154
1155
1157 XMPP element
1158
1159 dnd
1160
1162 4.3.12 PIDF Note Element
1164 A PIDF element may contain a child that provides a
1165 user-defined, natural-language description of the sender's detailed
1166 availability state. The PIDF element maps to the XMPP
1167 element.
1169 Example: Note Element
1171 PIDF element
1172
1173
1176
1177
1178 open
1179 busy
1180
1181 Wooing Juliet
1182
1183
1185 XMPP element
1186
1187 dnd
1188 Wooing Juliet
1189
1191 A PIDF document with zero tuples MAY contain one or more
1192 elements as direct children of the PIDF element. There is
1193 no mapping of such a PIDF document to an XMPP presence stanza; an
1194 entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send
1195 such a PIDF document to an XMPP recipient if possible, and an
1196 XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP
1197 presence stanza (see Zero Resources (Section 5.4.2)).
1199 4.3.13 PIDF Contact Element
1201 The core XMPP specification does not include syntax for specifying
1202 the URL of a contact address, since the contact address is implicit
1203 in the 'from' attribute of the XMPP presence stanza. Therefore, if an
1204 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
1205 PIDF object that contains a element, it SHOULD NOT pass
1206 the CDATA of the element on to the XMPP recipient.
1207 However, the gateway MAY map the 'priority' element as specified in
1208 the following section.
1210 Example: PIDF Contact Element
1212 PIDF element
1213
1214
1216
1217 ...
1218 im:romeo@montague.net
1219
1220
1222 XMPP presence stanza
1223
1225 4.3.14 Presence Priority
1227 The child of the PIDF element MAY possess a
1228 'priority' attribute whose value is a decimal number between zero and
1229 one (with a maximum of three decimal places). The value of this
1230 attribute MAY be mapped to the child element of an XMPP
1231 presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
1232 values to negative values of the XMPP element. If an
1233 XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
1234 priority='0' as XMPP 0 and PIDF priority='1' as
1235 127, mapping intermediate values appropriately
1236 so that they are unique (e.g., PIDF priorities between 0.001 and
1237 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to
1238 XMPP priority 2, and so on up through mapping PIDF priorities between
1239 0.992 and 0.999 to XMPP priority 126; note that this is an example
1240 only, and that the exact mapping shall be determined by the XMPP-CPIM
1241 gateway).
1243 4.3.15 PIDF Timestamp Element
1245 The core XMPP specification does not include syntax for specifying
1246 the datetime or timestamp at which a presence stanza was sent.
1247 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1248 with encapsulated PIDF object that contains a element,
1249 it SHOULD NOT pass that information on to the XMPP recipient.
1251 5. XMPP-CPIM Gateway as Presence Service
1253 CPP [3] defines semantics for an abstract presence service. An
1254 XMPP-CPIM gateway MAY function as such a presence service, and if so
1255 an XMPP entity can use defined XMPP syntax to interact with the
1256 gateway's presence service. Because PIDF [5] does not specify syntax
1257 for semantic operations such as subscribe, this section defines only
1258 the XMPP interactions with the presence service offered by an
1259 XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
1260 (Note: detailed information about XMPP presence services can be found
1261 in XMPP IM [7]; as much as possible, an XMPP-CPIM gateway SHOULD
1262 implement the syntax, semantics, and server business rules defined
1263 therein.)
1265 5.1 Requesting a Subscription
1267 If an XMPP entity wants to subscribe to the presence information of a
1268 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1269 presence stanza of type "subscribe" to the target presentity. The
1270 syntax mapping is as follows:
1272 o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP
1273 "watcher parameter" field (pres:node@domain). The XMPP-CPIM
1274 gateway MUST append the "pres:" Presence URI scheme to the front
1275 of the address.
1277 o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP
1278 "target parameter" field (pres:node@domain). The XMPP-CPIM gateway
1279 MUST append the "pres:" Presence URI scheme to the front of the
1280 address.
1282 o There is no XMPP mapping for the CPP "duration parameter", since
1283 XMPP subscriptions are active until they have been explicitly
1284 "unsubscribed" (see Subscription Durations (Section 5.3)).
1286 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1287 field.
1289 If the target presentity approves the subscription request (through
1290 whatever protocol it uses to interact with the gateway), the
1291 XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
1292 to the XMPP entity and notify the XMPP entity of the target's current
1293 available presence. Thereafter, until the subscription is cancelled,
1294 the gateway MUST notify the subscribing XMPP entity every time the
1295 target's presence information changes.
1297 If the target presentity denies the subscription request, the
1298 XMPP-CPIM gateway MUST return a presence stanza of type
1299 "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
1300 operation.
1302 In addition to the approval and denial cases, one of the following
1303 exceptions MAY occur:
1305 o The target parameter (XMPP "to" address) does not refer to a valid
1306 presentity; if this exception occurs, the XMPP-CPIM gateway MUST
1307 return an stanza error to the XMPP entity.
1309 o Access control rules do not permit the entity to subscribe to the
1310 target; if this exception occurs, the XMPP-CPIM gateway MUST
1311 return a stanza error to the XMPP entity.
1313 o There exists a pre-existing subscription or in-progress subscribe
1314 operation between the XMPP entity and the target presentity; if
1315 this exception occurs, the XMPP-CPIM gateway SHOULD return a
1316 stanza error to the XMPP entity.
1318 5.2 Receiving a Subscription Request
1320 If a non-XMPP presentity wants to subscribe to the presence
1321 information of an XMPP entity through an XMPP-CPIM gateway, it MUST
1322 use whatever protocol it uses to interact with the gateway in order
1323 to request the subscription; subject to local access rules, the
1324 gateway MUST then send a presence stanza of type "subscribe" to the
1325 XMPP entity from the non-XMPP watcher. The syntax mapping is as
1326 follows:
1328 o The CPP "watcher parameter" field (pres:node@domain) MUST be
1329 mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM
1330 gateway MUST remove the "pres:" Presence URI scheme from the front
1331 of the address.
1333 o The CPP "target parameter" field (pres:node@domain) MUST be mapped
1334 to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway
1335 MUST remove the "pres:" Presence URI scheme from the front of the
1336 address.
1338 o There is no XMPP mapping for the CPP "duration parameter", since
1339 XMPP subscriptions are active until they have been explicitly
1340 "unsubscribed" (see Subscription Durations (Section 5.3)).
1342 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1343 field.
1345 If the target XMPP entity approves the subscription request, it MUST
1346 send a presence stanza of type "subscribed" to the watcher
1347 presentity. The XMPP-CPIM gateway MUST then notify the watcher
1348 presentity of the target XMPP entity's current available presence.
1349 Thereafter, until the subscription is cancelled, the gateway MUST
1350 notify the watcher presentity every time the target's presence
1351 information changes.
1353 If the target XMPP entity denies the subscription request, it MUST
1354 send a presence stanza of type "unsubscribed" to the watcher
1355 presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
1356 operation.
1358 In addition to the approval and denial cases, one of the following
1359 exceptions MAY occur:
1361 o The target parameter (XMPP "to" address) does not refer to a valid
1362 XMPP entity
1364 o Access control rules do not permit the watcher presentity to
1365 subscribe to the target XMPP entity
1367 o There exists a pre-existing subscription or in-progress subscribe
1368 operation between the watcher presentity and the target XMPP
1369 entity
1371 If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
1372 the watcher presentity of failure.
1374 5.3 Subscription Durations
1376 XMPP services assume that a subscription is active until it is
1377 explicitly terminated. With the exception of handling duration
1378 parameters whose value is zero, handling duration parameters will be
1379 highly dependent on the implementation and requirements of the
1380 XMPP-CPIM gateway. Since there are no explicit requirements for
1381 supporting a "duration parameter" specified in either RFC 2778 [9] or
1382 RFC 2779 [1], duration parameter mapping is a local issue that falls
1383 outside the scope of this document.
1385 5.4 The Notify Operation
1387 An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
1388 presence information associated with an XMPP entity or CPP presentity
1389 changes and there are subscribers to that information on the other
1390 side of the gateway. The syntax mapping for presence information
1391 related to a notify operation is defined under Mapping for Presence
1392 (Section 4).
1394 5.4.1 Multiple Resources
1396 Semantically, PIDF contains the notion of multiple presence "tuples".
1397 Normally, a PIDF document will contain at least one tuple but MAY
1398 contain more than one tuple (or zero tuples, for which see next
1399 section). In the terminology of XMPP, each tuple would map to
1400 presence information for a separate resource. However, XMPP does not
1401 include the ability to send presence information about more than one
1402 resource at a time, since the resource that generates the presence
1403 information is contained in the 'from' address of a presence stanza.
1404 Therefore, an XMPP-CPIM gateway that acts as a presence service
1405 SHOULD split a PIDF document that contains multiple tuples into
1406 multiple XMPP presence stanzas, and SHOULD generate only one PIDF
1407 document (with multiple tuples) if an XMPP user currently has
1408 multiple connected resources.
1410 In the interest of not multiplying XMPP stanzas beyond necessity, an
1411 XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the
1412 presence information contained in a PIDF tuple communicates a change
1413 in the availability status of the device or application associated
1414 with that tuple ID.
1416 In the interest of complying with the PIDF recommendation to provide
1417 information about multiple "resources" in multiple tuples rather than
1418 in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
1419 information about all of an XMPP user's resources in one PIDF
1420 document (with one tuple for each resource), even if the availability
1421 status of only one resource has changed.
1423 5.4.2 Zero Resources
1425 A PIDF document may contain zero tuples. For example:
1427 PIDF Document with Zero Tuples
1429
1432 Because (1) the 'entity' attribute of a PIDF element maps
1433 to the portion of an XMPP JID and (2) the 'id' attribute
1434 of a PIDF element maps to the resource identifier portion of
1435 an XMPP JID, a PIDF document that contains zero tuples would provide
1436 presence information about a rather than a when mapped to XMPP. However, the notion of presence about
1438 a user rather than a user's resources is meaningless in the XMPP
1439 context. Therefore, an XMPP-CPIM gateway MUST NOT map a PIDF document
1440 with zero tuples into an XMPP presence stanza, and MUST NOT generate
1441 such a PIDF document when receiving a presence stanza from an XMPP
1442 entity (i.e., all PIDF documents generated by the gateway MUST
1443 contain at least one element).
1445 5.5 Unsubscribing
1447 If an XMPP entity wants to unsubscribe from the presence of a
1448 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1449 presence stanza of type "unsubscribe" to the target presentity. The
1450 syntax mapping is as follows:
1452 o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP
1453 "watcher parameter" field (pres:node@domain). The XMPP-CPIM
1454 gateway MUST append the "pres:" Presence URI scheme to the front
1455 of the address.
1457 o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP
1458 "target parameter" field (pres:node@domain). The XMPP-CPIM gateway
1459 MUST append the "pres:" Presence URI scheme to the front of the
1460 address.
1462 o The CPP "duration parameter" MUST be set to zero.
1464 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1465 field.
1467 If the target parameter (XMPP "to" address) does not refer to a valid
1468 presentity, the XMPP-CPIM gateway MUST return an
1469 stanza error to the XMPP entity.
1471 Upon receiving the presence stanza of type "unsubscribe" from the
1472 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1473 notifications to the XMPP entity.
1475 5.6 Cancelling a Subscription
1477 If an XMPP entity wants to cancel a non-XMPP presentity's
1478 subscription to the entity's presence through an XMPP-CPIM gateway,
1479 it MUST send a presence stanza of type "unsubscribed" to the target
1480 presentity. The syntax mapping is as follows:
1482 o The CPP "watcher parameter" field (pres:node@domain) MUST be
1483 mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM
1484 gateway MUST remove the "pres:" Presence URI scheme from the front
1485 of the address.
1487 o The CPP "target parameter" field (pres:node@domain) MUST be mapped
1488 to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway
1489 MUST remove the "pres:" Presence URI scheme from the front of the
1490 address.
1492 o The CPP "duration parameter" MUST be set to zero.
1494 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1495 field.
1497 Upon receiving the presence stanza of type "unsubscribed" from the
1498 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1499 notifications to the watcher presentity.
1501 6. Mapping of Character Encodings
1503 The following rules apply to the mapping of character encodings
1504 (charsets):
1506 1. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1507 other than "us-ascii", "utf-8", or "utf-16".
1509 2. A gateway SHOULD map a "Message/CPIM" object whose charset is
1510 "us-ascii" no matter whether the character encoding negotiated
1511 for the XMPP recipient's XML stream is UTF-8 or UTF-16.
1513 3. A gateway SHOULD map a "Message/CPIM" object whose charset is
1514 "utf-8" if the character encoding negotiated for the XMPP
1515 recipient's XML stream is UTF-8.
1517 4. A gateway SHOULD map a "Message/CPIM" object whose charset is
1518 "utf-16" if the character encoding negotiated for the XMPP
1519 recipient's XML stream is UTF-16.
1521 5. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1522 "utf-8" if the character encoding negotiated for the XMPP
1523 recipient's XML stream is UTF-16.
1525 6. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1526 "utf-16" if the character encoding negotiated for the XMPP
1527 recipient's XML stream is UTF-8.
1529 7. Security Considerations
1531 Detailed security considerations for instant messaging and presence
1532 protocols are given in RFC 2779 [1], specifically in Sections 5.1
1533 through 5.4.
1535 This document specifies methods for exchanging instant messages and
1536 presence information through a gateway that implements CPIM [2] and
1537 CPP [3]. Such a gateway MUST be compliant with the minimum security
1538 requirements of the instant messaging and presence protocols with
1539 which it interfaces. The introduction of gateways to the security
1540 model of instant messaging and presence in RFC 2779 also introduces
1541 some new risks. In particular, end-to-end security properties
1542 (especially confidentiality and integrity) between instant messaging
1543 and presence user agents that interface through an XMPP-CPIM gateway
1544 can be provided only if common formats are supported; these formats
1545 are specified fully in End-to-End Object Encryption in XMPP [8].
1547 Normative References
1549 [1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
1550 Presence Protocol Requirements", RFC 2779, February 2000.
1552 [2] Crocker, D. and J. Peterson, "Common Profile for Instant
1553 Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress),
1554 March 2003.
1556 [3] Crocker, D. and J. Peterson, "Common Profile for Presence
1557 (CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003.
1559 [4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
1560 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
1561 progress), January 2003.
1563 [5] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and
1564 J. Peterson, "CPIM Presence Information Data Format",
1565 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
1567 [6] Saint-Andre, P. and J. Miller, "XMPP Core",
1568 draft-ietf-xmpp-core-17 (work in progress), August 2003.
1570 [7] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
1571 draft-ietf-xmpp-im-16 (work in progress), August 2003.
1573 [8] Saint-Andre, P., "End-to-End Object Encryption in XMPP",
1574 draft-ietf-xmpp-e2e-04 (work in progress), June 2003.
1576 [9] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
1577 Instant Messaging", RFC 2778, February 2000, .
1580 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1581 Levels", BCP 14, RFC 2119, March 1997.
1583 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1584 Extensions (MIME) Part One: Format of Internet Message Bodies",
1585 RFC 2045, November 1996.
1587 Informative References
1589 [12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
1591 [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1592 Extensions (MIME) Part Two: Media Types", RFC 2046, November
1593 1996.
1595 Authors' Addresses
1597 Peter Saint-Andre
1598 Jabber Software Foundation
1600 EMail: stpeter@jabber.org
1602 Tony Bamonti
1603 Jabber, Inc.
1605 EMail: tbamonti@jabber.com
1607 Appendix A. Revision History
1609 Note to RFC Editor: please remove this entire appendix, and the
1610 corresponding entries in the table of contents, prior to publication.
1612 A.1 Changes from draft-ietf-xmpp-cpim-01
1614 o Added subsection about handling presence notifications for
1615 multiple XMPP resources and multiple PIDF tuples.
1617 o Added subsection about PIDF documents that contain zero tuples.
1619 o Further specified mapping between XMPP JIDs and CPIM instant
1620 inboxes and presentities.
1622 A.2 Changes from draft-ietf-xmpp-cpim-00
1624 o Updated references.
1626 o Made several small editorial changes.
1628 Intellectual Property Statement
1630 The IETF takes no position regarding the validity or scope of any
1631 intellectual property or other rights that might be claimed to
1632 pertain to the implementation or use of the technology described in
1633 this document or the extent to which any license under such rights
1634 might or might not be available; neither does it represent that it
1635 has made any effort to identify any such rights. Information on the
1636 IETF's procedures with respect to rights in standards-track and
1637 standards-related documentation can be found in BCP-11. Copies of
1638 claims of rights made available for publication and any assurances of
1639 licenses to be made available, or the result of an attempt made to
1640 obtain a general license or permission for the use of such
1641 proprietary rights by implementors or users of this specification can
1642 be obtained from the IETF Secretariat.
1644 The IETF invites any interested party to bring to its attention any
1645 copyrights, patents or patent applications, or other proprietary
1646 rights which may cover technology that may be required to practice
1647 this standard. Please address the information to the IETF Executive
1648 Director.
1650 Full Copyright Statement
1652 Copyright (C) The Internet Society (2003). All Rights Reserved.
1654 This document and translations of it may be copied and furnished to
1655 others, and derivative works that comment on or otherwise explain it
1656 or assist in its implementation may be prepared, copied, published
1657 and distributed, in whole or in part, without restriction of any
1658 kind, provided that the above copyright notice and this paragraph are
1659 included on all such copies and derivative works. However, this
1660 document itself may not be modified in any way, such as by removing
1661 the copyright notice or references to the Internet Society or other
1662 Internet organizations, except as needed for the purpose of
1663 developing Internet standards in which case the procedures for
1664 copyrights defined in the Internet Standards process must be
1665 followed, or as required to translate it into languages other than
1666 English.
1668 The limited permissions granted above are perpetual and will not be
1669 revoked by the Internet Society or its successors or assignees.
1671 This document and the information contained herein is provided on an
1672 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1673 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1674 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1675 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1676 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1678 Acknowledgment
1680 Funding for the RFC Editor function is currently provided by the
1681 Internet Society.