idnits 2.17.1
draft-ietf-xmpp-cpim-03.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 (November 20, 2003) is 7456 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 2778 (ref.
'IMP-MODEL')
** Downref: Normative reference to an Informational RFC: RFC 2779 (ref.
'IMP-REQS')
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
== Outdated reference: A later version (-24) exists of
draft-ietf-xmpp-core-20
== Outdated reference: A later version (-09) exists of
draft-ietf-xmpp-e2e-06
== Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-19
-- Obsolete informational reference (is this intentional?): RFC 2822
(Obsoleted by RFC 5322)
Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 XMPP Working Group P. Saint-Andre
2 Internet-Draft Jabber Software Foundation
3 Expires: May 20, 2004 November 20, 2003
5 Mapping the Extensible Messaging and Presence Protocol (XMPP) to
6 Common Presence and Instant Messaging (CPIM)
7 draft-ietf-xmpp-cpim-03
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at http://
24 www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on May 20, 2004.
31 Copyright Notice
33 Copyright (C) The Internet Society (2003). All Rights Reserved.
35 Abstract
37 This memo describes a mapping of the Extensible Messaging and
38 Presence Protocol (XMPP) to the Common Presence and Instant Messaging
39 (CPIM) specifications.
41 Table of Contents
43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
44 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
45 3. Mapping of Instant Messages . . . . . . . . . . . . . . . . . 5
46 4. Mapping of Presence . . . . . . . . . . . . . . . . . . . . . 13
47 5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26
48 6. Internationalization Considerations . . . . . . . . . . . . . 31
49 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
50 Normative References . . . . . . . . . . . . . . . . . . . . . 32
51 Informative References . . . . . . . . . . . . . . . . . . . . 33
52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34
53 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 34
54 Intellectual Property and Copyright Statements . . . . . . . . 35
56 1. Introduction
58 1.1 Overview
60 The Instant Messaging and Presence (IMPP) Working Group has defined
61 an abstract framework for interoperability among instant messaging
62 (IM) and presence systems that are compliant with [IMP-REQS]. This
63 framework is commonly called Common Presence and Instant Messaging or
64 "CPIM". The CPIM family of specifications include a Common Profile
65 for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
66 Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
67 Information Data Format [PIDF]. (Note: To prevent confusion, Common
68 Presence and Instant Messaging is referred to herein collectively as
69 "the CPIM specifications", whereas the Common Profile for Instant
70 Messaging is referred to as "CPIM". In order to refer to a gateway
71 between an Extensible Messaging and Presence Protocol (XMPP) service
72 and a non-XMPP service where the common format is defined by the CPIM
73 specifications, the term "XMPP-CPIM Gateway" is used herein.)
75 This memo describes how the Extensible Messaging and Presence
76 Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
77 contained in the CPIM specifications, mainly for the purpose of
78 establishing gateways between XMPP services and non-XMPP services
79 that conform to [IMP-REQS]. Such gateways may be established to
80 interpret the protocols of one service and translate them into the
81 protocols of the other service. We can visualize this relationship
82 as follows:
84 +-------------+ +-------------+ +------------+
85 | | | | | |
86 | XMPP | | XMPP-CPIM | | Non-XMPP |
87 | Service | <----> | Gateway | <----> | Service |
88 | | | | | |
89 +-------------+ +-------------+ +------------+
91 This memo defines a mapping for use by a gateway that translates
92 between XMPP and a non-XMPP protocol via the CPIM specifications.
93 Such a gateway is not an intermediate hop on a network of non-XMPP
94 servers (whose native formats may or may not be defined by the CPIM
95 specifications), but a dedicated translator between XMPP and a
96 non-XMPP protocol, where the CPIM specifications define the common
97 formats into which the protocols are translated for purposes of
98 interworking.
100 The mapping defined herein applies to instant messages and presence
101 information that are not encrypted or signed for end-to-end security.
102 For information about secure communications to or from an XMPP
103 service through an XMPP-CPIM gateway, refer to [XMPP-E2E].
105 1.2 Terminology
107 This memo inherits vocabulary defined in [IMP-MODEL]. Terms such as
108 CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
109 PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
110 defined therein.
112 This memo also inherits vocabulary defined in [XMPP-CORE]. Terms
113 such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
114 IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
115 meaning as defined therein.
117 1.3 Conventions Used in this Document
119 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
120 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
121 "OPTIONAL" in this document are to be interpreted as described in
122 [TERMS].
124 1.4 Discussion Venue
126 The authors welcome discussion and comments related to the topics
127 presented in this document. The preferred forum is the
128 mailing list, for which archives and subscription
129 information are available at .
132 1.5 Intellectual Property Notice
134 This document is in full compliance with all provisions of Section 10
135 of RFC 2026. Parts of this specification use the term "jabber" for
136 identifying namespaces and other protocol syntax. Jabber[tm] is a
137 registered trademark of Jabber, Inc. Jabber, Inc. grants permission
138 to the IETF for use of the Jabber trademark in association with this
139 specification and its successors, if any.
141 1.6 Contributors
143 Tony Bamonti contributed to the first version of this memo.
145 2. Approach
147 XMPP and CPIM are distinctly foreign technologies. Therefore, care
148 must be taken in mapping between XMPP and the abstract syntax defined
149 by the CPIM specifications.
151 At root, XMPP is a data transport protocol for streaming XML elements
152 (called "stanzas") between any two endpoints on the network; message
153 and presence stanzas are two of the core data elements defined in
154 XMPP and are often used to exchange instant messages and presence
155 information between IM users (although the inherent extensibility of
156 XML enables applications to use the general semantics of these stanza
157 types for other purposes). XMPP is not based on [MIME]; instead,
158 [XMPP-CORE] defines XML schemas for both message and presence stanzas
159 (for example, the child of a message stanza contains XML
160 character data that is usually intended to be read by a human user).
162 The CPIM specifications provide common formats for instant messaging
163 and presence through two [MIME] content-types: "Message/CPIM" for
164 messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]).
165 The syntax of "Message/CPIM" objects is similar to but stricter than
166 that defined in [RFC2822], and provides the ability to include
167 arbitrary MIME media types [MIMETYPES]. By contrast, each
168 "application/pidf+xml" object is a complete XML document whose
169 structure is defined by an XML schema.
171 The approach taken herein is to specify mappings from XMPP elements
172 and attributes to the headers and MIME formats defined by [MSGFMT]
173 and [PIDF] in order to comply with the semantics defined by [CPIM]
174 and [CPP]. Naturally, mappings in the opposite direction are
175 provided as well.
177 3. Mapping of Instant Messages
179 This section describes how a gateway SHOULD map instant messages
180 between an XMPP service and a non-XMPP service using a "Message/CPIM"
181 object as the bearer of encapsulated text content in order to comply
182 with the instant messaging semantics defined by [CPIM].
184 3.1 Identification of Instant Inboxes
186 There is a one-to-one relationship between an XMPP entity and a CPIM
187 instant inbox when the address of the XMPP entity contains only a
188 node identifier and domain identifier, and the node identifier
189 uniquely corresponds to an IM user who possesses an account on an
190 XMPP server. However, the syntax for addressing an instant inbox is
191 specified as including the 'im:' URI scheme as defined in [CPIM],
192 whereas an XMPP address does not include that scheme, so any mapping
193 between an instant inbox address and an XMPP address must add or
194 remove the 'im:' URI scheme as appropriate.
196 3.2 Message Syntax Mapping from XMPP to CPIM Specifications
198 This section defines the mapping of syntax primitives from XMPP
199 message stanzas to "Message/CPIM" objects with encapsulated text
200 content.
202 3.2.1 From Address
204 The 'from' attribute of an XMPP message stanza maps to the 'From'
205 header of a "Message/CPIM" object. In XMPP, the sender's server
206 stamps or validates the "from" address and sets its value to the full
207 negotiated between client and server during
208 authentication and resource binding as defined in [XMPP-CORE]. Thus
209 an XMPP-CPIM gateway will receive from the sender's XMPP server a
210 message stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP message stanza to
212 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
213 the resource identifier, MUST append the "im:" Instant Messaging URI
214 scheme to the front of the address, and MAY include a CPIM
215 "Formal-name" for the sender (if known).
217 Example: From Address Mapping
219 XMPP 'from' attribute
220
221 ...
222
224 CPIM 'From' header
225 From: Juliet Capulet
227 3.2.2 To Address
229 The 'to' attribute of an XMPP message stanza maps to the 'To' header
230 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a
231 'to' attribute on a message stanza, and MUST include it if the
232 message is intended for delivery to another user. Thus an XMPP-CPIM
233 gateway will receive from the sender's XMPP server a message stanza
234 containing a "to" address of the form or . To map the 'to' attribute of an XMPP message stanza to
236 the 'To' header of a "Message/CPIM" object, the gateway MUST remove
237 the resource identifier (if included), MUST append the "im:" Instant
238 Messaging URI scheme to the front of the address, and MAY include a
239 CPIM "Formal-name" for the recipient (if known).
241 Example: To Address Mapping
243 XMPP 'to' attribute
244
245 ...
246
248 CPIM 'To' header
249 To: Romeo Montague
251 3.2.3 CPIM Courtesy Copy
253 The core XMPP specification does not include syntax for specifying a
254 "courtesy copy" (non-primary addressee) for a message stanza.
255 Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
256 of a "Message/CPIM" object.
258 3.2.4 XMPP Stanza ID
260 An XMPP message stanza MAY possess an 'id' attribute, which is used
261 by the sending application for the purpose of tracking stanzas.
262 There is no mapping of an XMPP 'id' attribute to a "Message/CPIM"
263 header, common MIME features, or encapsulated text content.
264 Therefore if an XMPP stanza received by an XMPP-CPIM gateway
265 possesses an 'id' attribute, the gateway SHOULD ignore the value
266 provided.
268 3.2.5 XMPP Message Type
270 An XMPP message stanza MAY possess a 'type' attribute, which is used
271 by the sending application to capture the conversational context of
272 the message. There is no mapping of an XMPP 'type' attribute to a
273 "Message/CPIM" header, common MIME features, or encapsulated text
274 content. Therefore if an XMPP stanza received by an XMPP-CPIM
275 gateway possesses a 'type' attribute, the gateway SHOULD ignore the
276 value provided.
278 3.2.6 XMPP Message Thread
280 An XMPP message stanza MAY contain a child element to
281 specify the conversation thread in which the message is situated.
282 There is no mapping of an XMPP element to a "Message/CPIM"
283 header, common MIME features, or encapsulated text content.
284 Therefore if an XMPP message stanza received by an XMPP-CPIM gateway
285 contains a child element, the gateway SHOULD ignore the
286 value provided.
288 3.2.7 CPIM DateTime Header
290 The core XMPP specification does not include syntax for specifying
291 the datetime at which a message stanza was sent. However, an
292 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
293 CPIM" object it generates, the value of which SHOULD be the datetime
294 at which the message stanza was received for processing by the
295 gateway.
297 3.2.8 Message Subject
299 An XMPP message stanza MAY include a child element. If
300 included, it maps to the 'Subject' header of a "Message/CPIM" object.
301 To map the XMPP element to the 'Subject' header of a
302 "Message/CPIM" object, the gateway SHOULD simply map the XML
303 character data of the XMPP element to the value of the
304 'Subject' header. The element MAY include an 'xml:lang'
305 attribute specifying the language in which the subject is written.
306 If an 'xml:lang' attribute is provided, it MUST be mapped by
307 including ';lang=tag' after the header name and colon, where 'tag' is
308 the value of the 'xml:lang' attribute.
310 Example: Subject Mapping
312 XMPP element
313 Hi!
314 Ahoj!
316 CPIM 'Subject' header
317 Subject: Hi!
318 Subject:;lang=cz Ahoj!
320 3.2.9 CPIM Header Extensions
322 A "Message/CPIM" object MAY include an optional 'NS' header to
323 specify the namespace of a feature extension. An XMPP-CPIM gateway
324 SHOULD NOT generate such headers.
326 3.2.10 CPIM Required Headers
328 A "Message/CPIM" object MAY include an optional 'Required' header to
329 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
330 NOT generate such headers.
332 3.2.11 MSGFMT MIME Content-type
334 As specified in [MIME], the default Content-type of a MIME object is
335 "Content-type: text/plain; charset=us-ascii". Because XMPP uses the
336 [UTF-8] character encoding exclusively, the encapsulated MIME object
337 generated by an XMPP-CPIM gateway MUST set the 'Content-type' header
338 for that object. The "Content-type" MUST be set to "text/plain" and
339 the charset MUST be set to UTF-8.
341 Example: Content-type for Encapsulated Object
343 Content-type: text/plain; charset=utf-8
345 3.2.12 MSGFMT MIME Content-ID
347 As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
348 While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
349 MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
350 values MUST be generated to be world-unique.
352 Example: Content-ID for Encapsulated Object
354 Content-ID: <123456789@example.net>
356 3.2.13 Message Body
358 The child element of an XMPP message stanza is used to
359 provide the primary meaning of the message. The XML character data
360 of the XMPP element maps to the encapsulated text message
361 content.
363 Example: Message Body
365 XMPP message
366
367 Wherefore art thou, Romeo?
368
370 Encapsulated MIME text content
371 Content-type: text/plain; charset=utf-8
372 Content-ID: <123456789@example.net>
374 Wherefore art thou, Romeo?
376 3.2.14 XMPP Message Extensions
378 As defined in [XMPP-CORE], an XMPP message stanza may contain
379 "extended" content in any namespace in order to supplement or extend
380 the semantics of the core message stanza. With the exception of
381 extended information qualified by the
382 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
383 an XMPP-CPIM gateway SHOULD ignore such information and not pass it
384 through the gateway to the intended recipient. No mapping for such
385 information is defined.
387 3.3 Message Syntax Mapping from CPIM Specifications to XMPP
389 This section defines the mapping of syntax primitives from "Message/
390 CPIM" objects with encapsualted text content to XMPP message stanzas.
392 3.3.1 From Address
394 The 'From' header of a "Message/CPIM" object maps to the 'from'
395 attribute of an XMPP message stanza. To map the CPIM 'From' header
396 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
397 Instant Messaging URI scheme from the front of the address and MUST
398 remove the CPIM "Formal-name" (if provided).
400 Example: From Address Mapping
402 CPIM 'From' header
403 From: Romeo Montague
405 XMPP 'from' attribute
406
407 ...
408
410 3.3.2 To Address
412 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
413 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP
414 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
415 URI scheme from the front of the address and MUST remove the CPIM
416 "Formal-name" (if provided). If the gateway possesses knowledge of
417 the resource identifier in use by the XMPP entity, the gateway MAY
418 append the resource identifier to the address.
420 Example: To Address Mapping
422 CPIM 'To' header
423 To: Juliet Capulet
425 XMPP 'to' attribute
426
427 ...
428
430 3.3.3 CPIM Courtesy Copy
432 The core XMPP specification does not include syntax for specifying a
433 "courtesy copy" (non-primary addressee) for a message stanza.
434 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
435 that contains a 'cc' header, it SHOULD NOT pass that information on
436 to the XMPP recipient.
438 3.3.4 XMPP Message Type
440 MSGFMT does not possess the concept of a message type that can map to
441 the XMPP 'type' attribute for message stanzas. Therefore an
442 XMPP-CPIM gateway SHOULD NOT include the 'type' attribute on the
443 messages it sends to XMPP recipients.
445 3.3.5 CPIM DateTime Header
447 The core XMPP specification does not include syntax for specifying
448 the datetime at which a message stanza was sent. Therefore, if an
449 XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
450 'DateTime' header, it SHOULD NOT pass that information on to the XMPP
451 recipient.
453 3.3.6 Message Subject
455 The 'Subject' header of a "Message/CPIM" object maps to the child element of an XMPP message stanza. To map the CPIM 'Subject'
457 header to the XMPP element, the gateway SHOULD simply map
458 the value of the 'Subject' header to the XML character data of the
459 XMPP element. The 'Subject' header MAY specify the "lang"
460 in which the subject is written. If "lang" information is provided,
461 it MUST be mapped to the 'xml:lang' attribute of the
462 element, where the value of the 'xml:lang' attribute is the the "tag"
463 value supplied in the string ';lang=tag' included CPIM 'Subject'
464 header name and colon.
466 Example: Subject Mapping
468 CPIM 'Subject' header
469 Subject: Hi!
470 Subject:;lang=cz Ahoj!
472 XMPP element
473 Hi!
474 Ahoj!
476 3.3.7 CPIM Header Extensions
478 "Message/CPIM" objects MAY include an optional 'NS' header to specify
479 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
480 pass such headers through to the XMPP recipient, and no mapping for
481 such headers is defined.
483 3.3.8 CPIM Required Headers
484 "Message/CPIM" objects MAY include an optional 'Required' header to
485 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
486 NOT pass such headers through to the XMPP recipient, and no mapping
487 for such headers is defined.
489 3.3.9 MSGFMT MIME Content-type
491 As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
492 arbitrary MIME content. However, support for arbitrary content types
493 is not a requirement in XMPP; in particular, the child
494 element of an XMPP message stanza MUST contain XML character data
495 only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP
496 message stanza a "Message/CPIM" object whose encapsulated MIME object
497 has a Content-type other than "text/plain" (with the exception of
498 multi-part MIME objects as specified in [XMPP-E2E]).
500 3.3.10 MSGFMT MIME Content-ID
502 XMPP does not include an element or attribute that captures a
503 globally unique ID as is defined for the Content-ID MIME header as
504 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
505 that includes a Content-ID, it MAY provide the Content-ID as the
506 value of the message stanza's 'id' attribute but is NOT REQUIRED to
507 do so.
509 Example: Content-ID for Encapsulated Object
511 MIME header
512 Content-ID: <123456789@example.net>
514 XMPP 'id' attribute (OPTIONAL)
515
516 ...
517
519 3.3.11 Message Body
521 If the Content-type of an encapsulated MIME object is "text/plain",
522 then the encapsulated text message content maps to the XML character
523 data of the child element of an XMPP message stanza.
525 Example: Message Body
527 Encapsulated MIME text content
528 Content-type: text/plain; charset=utf-8
529 Content-ID: <123456789@example.net>
530 Wherefore art thou?
532 XMPP message
533
534 Wherefore art thou?
535
537 4. Mapping of Presence
539 This section describes how a gateway SHOULD map presence information
540 between an XMPP service and a non-XMPP service using a "Message/CPIM"
541 object as the bearer of an encapsulated [PIDF] object in order to
542 comply with the presence semantics defined by [CPP].
544 4.1 Identification of Presentities
546 There is a one-to-one relationship between an XMPP entity and a CPP
547 presentity when the address of the XMPP entity contains only a node
548 identifier and domain identifier, and the node identifier uniquely
549 corresponds to an IM user who possesses an account on an XMPP server.
550 However, the syntax of presentities is specified as including the
551 'pres:' URI scheme as defined in [CPP], whereas XMPP addresses do not
552 include that scheme, so any mapping between presentities and XMPP
553 addresses must add or remove the 'pres:' URI scheme as appropriate.
555 4.2 Presence Syntax Mapping from XMPP to CPIM Specifications
557 This section defines the mapping of syntax primitives from XMPP
558 presence stanzas to "Message/CPIM" objects with encapsulated
559 "application/pidf+xml" objects.
561 4.2.1 From Address
563 The 'from' attribute of an XMPP presence stanza maps to the 'From'
564 header of a "Message/CPIM" object. In XMPP, the sender's server
565 stamps or validates the "from" address and sets its value to the
566 negotiated between client and server during
567 authenticating and resource binding as defined in [XMPP-CORE]. Thus
568 an XMPP-CPIM gateway will receive from the sender's XMPP server a
569 presence stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP presence stanza to
571 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
572 the resource identifier, MUST append the "im:" Instant Messaging URI
573 scheme to the front of the address, and MAY include a CPIM
574 "Formal-name" for the sender (if known).
576 Example: From Address Mapping
577 XMPP 'from' attribute
578
579 ...
580
582 CPIM 'From' header
583 From: Juliet Capulet
585 In addition, the 'from' attribute of an XMPP presence stanza maps to
586 the 'entity' attribute of a PIDF root element. To map
587 the XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
588 MUST remove the resource identifier and MUST append the "pres:"
589 Instant Messaging URI scheme to the front of the address.
591 Example: From Address Mapping (PIDF)
593 XMPP 'from' attribute
594
595 ...
596
598 PIDF 'entity' attribute
599
600 ...
601
603 Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
604 the XMPP address contained in the XMPP 'from' attribute to the 'id'
605 attribute of the PIDF child element.
607 Example: Resource Identifier Mapping
609 XMPP 'from' attribute
610
611 ...
612
614 PIDF 'id' for
615
616
617 ...
618
619
621 4.2.2 To Address
623 The 'to' attribute of an XMPP presence stanza maps to the 'To' header
624 of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to'
625 attribute on a presence stanza, and MUST include it if the presence
626 stanza is intended for delivery directly to another user (presence
627 stanzas intended for broadcasting are stamped with a 'to' address by
628 the sender's server). Thus an XMPP-CPIM gateway will receive from
629 the sender's XMPP server a presence stanza containing a "to" address
630 of the form or . To map the 'to'
631 attribute of an XMPP presence stanza to the 'To' header of a
632 "Message/CPIM" object, the gateway MUST remove the resource
633 identifier (if included), MUST append the "im:" Instant Messaging URI
634 scheme to the front of the address, and MAY include a CPIM
635 "Formal-name" for the recipient (if known).
637 Example: To Address Mapping
639 XMPP 'to' attribute
640
641 ...
642
644 CPIM 'To' header
645 To: Romeo Montague
647 4.2.3 CPIM Courtesy Copy
649 The core XMPP specification does not include syntax for specifying a
650 "courtesy copy" (non-primary addressee) for a presence stanza.
651 Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
652 of a "Message/CPIM" object.
654 4.2.4 XMPP Stanza ID
656 An XMPP presence stanza MAY possess an 'id' attribute, which is used
657 by the sending application for the purpose of tracking stanzas.
658 There is no mapping of an XMPP 'id' attribute to a "Message/CPIM"
659 header, common MIME features, or PIDF elements and attributes.
660 Therefore if an XMPP stanza received by an XMPP-CPIM gateway
661 possesses an 'id' attribute, the gateway SHOULD ignore the value
662 provided.
664 4.2.5 CPIM DateTime Header
666 The core XMPP specification does not include syntax for specifying
667 the datetime at which a presence stanza was sent. However, an
668 XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
669 CPIM" object it generates, the value of which SHOULD be the datetime
670 at which the presence stanza was received for processing by the
671 gateway.
673 4.2.6 CPIM Subject Header
675 An XMPP presence stanza contains no information that can be mapped to
676 the 'Subject' header of a "Message/CPIM" object. Therefore an
677 XMPP-CPIM gateway SHOULD NOT generate such headers when mapping XMPP
678 presence stanzas.
680 4.2.7 CPIM Header Extensions
682 A "Message/CPIM" object MAY include an optional 'NS' header to
683 specify the namespace of a feature extension. An XMPP-CPIM gateway
684 SHOULD NOT generate such headers.
686 4.2.8 CPIM Required Headers
688 A "Message/CPIM" object MAY include an optional 'Required' header to
689 specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
690 NOT generate such headers.
692 4.2.9 PIDF MIME Content-type
694 As specified in [MIME], the default Content-type of a MIME object is
695 "Content-type: text/plain; charset=us-ascii". Because XMPP uses the
696 [UTF-8] character encoding exclusively and because PIDF specifies the
697 "application/pidf+xml" MIME time, the encapsulated MIME object
698 generated by an XMPP-CPIM gateway for presence information MUST set
699 the 'Content-type' header for that object. The "Content-type" MUST
700 be set to "application/pidf+xml" and the charset MUST be set to
701 UTF-8.
703 Example: Content-type for Encapsulated PIDF Object
705 Content-type: application/pidf+xml; charset=utf-8
707 4.2.10 PIDF MIME Content-ID
709 As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
710 While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
711 MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
712 values MUST be generated to be world-unique.
714 Example: Content-ID for Encapsulated Object
716 Content-ID: <123456789@example.net>
718 4.2.11 XMPP Presence Type
720 An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
721 attribute is included, the presence stanza indicates that the sender
722 is available; this state maps to the PIDF basic presence type of
723 OPEN. If the 'type' attribute has a value of "unavailable", the
724 presence stanza indicates that the sender is no longer available;
725 this state maps to the PIDF basic presence type of CLOSED. Thus both
726 the absence of a 'type' attribute and a 'type' attribute set to a
727 value of "unavailable" correspond to the [CPP] "notify operation".
728 All other presence types are used to manage presence subscriptions or
729 probe for current presence; mappings for these other presence types
730 are defined under XMPP-CPIM Gateway as Presence Service (Section 5).
732 Example: Available Presence
734 XMPP available presence
735
737 PIDF basic presence (OPEN)
738
739
741
742
743 open
744
745
746
748 Example: Unavailable Presence
750 XMPP unavailable presence
751
753 PIDF basic presence (CLOSED)
754
755
757
758
759 closed
760
761
762
764 4.2.12 XMPP Show Element
766 The child element of an XMPP presence stanza provides
767 additional information about the sender's availability. The XML
768 character data of the XMPP element maps to extended
769 content in PIDF. The defined values of the element are
770 'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for
771 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
772 namespace, the XMPP values will be mapped to the PIDF values.
774 Example: Show Element
776 XMPP element
777
778 away
779
781 PIDF extended presence information
782
783
786
787
788 open
789 away
790
791
792
794 4.2.13 XMPP Status Element
796 The child element of an XMPP presence stanza provides a
797 user-defined, natural-language description of the sender's detailed
798 availability state. The XMPP element maps to the PIDF
799 child of the PIDF element.
801 Example: Status Element
803 XMPP element
804
805 away
806 retired to the chamber
807
809 PIDF element
810
811
814
815
816 open
817 away
818
819 retired to the chamber
820
821
823 4.2.14 PIDF Contact Element
825 The core XMPP specification does not include syntax for specifying
826 the URL of a contact address, since the contact address is implicit
827 in the 'from' attribute of the XMPP presence stanza. However, an
828 XMPP-CPIM gateway MAY include the child of the
829 element, the value of which SHOULD be the of the XMPP
830 sender, prepended by the "im:" Instant Messaging URI scheme.
832 Example: PIDF Contact Element
834 XMPP presence stanza
835
837 PIDF element
838
839
841
842 ...
843 im:juliet@example.com
844
845
847 4.2.15 Presence Priority
849 An XMPP presence stanza MAY contain a child element whose
850 value is an integer between -128 and +127. The value of this element
851 MAY be mapped to the 'priority' attribute of the child of
852 the PIDF element. If the value of the XMPP
853 element is negative, an XMPP-CPIM gateway MUST NOT map the value.
854 The range of allowable values for the PIDF 'priority' attribute is
855 any decimal number from zero to one inclusive, with a maximum of
856 three decimal places. If an XMPP-CPIM gateway maps these values, it
857 SHOULD treat XMPP 0 as PIDF priority='0' and
858 XMPP 127 as PIDF priority='1', mapping
859 intermediate values appropriately so that they are unique (e.g., XMPP
860 priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority
861 0.015, and so on up through mapping XMPP priority 126 to PIDF
862 priority 0.992; note that this is an example only, and that the exact
863 mapping shall be determined by the XMPP-CPIM gateway).
865 Example: Presence Priority
867 XMPP element
868
869 13
870
872 PIDF element
873
874
876
877 ...
878 im:juliet@example.com
879
880
882 4.2.16 PIDF Timestamp Element
884 The core XMPP specification does not include syntax for specifying
885 the datetime at which a presence stanza was sent. However, an
886 XMPP-CPIM gateway MAY include a element within the PIDF
887 document it generates, the value of which SHOULD be the datetime at
888 which the presence stanza was received for processing by the gateway.
890 4.2.17 XMPP Presence Extensions
892 As defined in [XMPP-CORE], an XMPP presence stanza may contain
893 "extended" content in any namespace in order to supplement or extend
894 the semantics of the core presence stanza. With the exception of
895 extended information qualified by the
896 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
897 an XMPP-CPIM gateway SHOULD ignore such information and not pass it
898 through the gateway to the intended recipient. No mapping for such
899 information is defined.
901 4.3 Presence Syntax Mapping from CPIM Specifications to XMPP
903 This section defines the mapping of syntax primitives from "Message/
904 CPIM" objects with encapsulated "application/pidf+xml" objects to
905 XMPP presence stanzas.
907 4.3.1 From Address
909 The 'From' header of a "Message/CPIM" object maps to the 'from'
910 attribute of an XMPP presence stanza. To map the CPIM 'From' header
911 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
912 Instant Messaging URI scheme from the front of the address and MUST
913 remove the CPIM "Formal-name" (if provided).
915 Example: From Address Mapping
917 CPIM 'From' header
918 From: Romeo Montague
920 XMPP 'from' attribute
921
922 ...
923
925 4.3.2 To Address
927 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
928 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
929 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
930 URI scheme from the front of the address and MUST remove the CPIM
931 "Formal-name" (if provided). If the gateway possesses knowledge of
932 the resource identifier in use by the XMPP entity, the gateway MAY
933 append the resource identifier to the address.
935 Example: To Address Mapping
937 CPIM 'To' header
938 To: Juliet Capulet
940 XMPP 'to' attribute
941
942 ...
943
945 4.3.3 CPIM Courtesy Copy
947 The core XMPP specification does not include syntax for specifying a
948 "courtesy copy" (non-primary addressee) for a presence stanza.
949 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
950 with encapsulated PIDF object that contains a 'cc' header, it SHOULD
951 NOT pass that information on to the XMPP recipient.
953 4.3.4 CPIM DateTime Header
955 The core XMPP specification does not include syntax for specifying
956 the datetime at which a presence stanza was sent. Therefore, if an
957 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
958 PIDF object that contains a 'DateTime' header, it SHOULD NOT pass
959 that information on to the XMPP recipient.
961 4.3.5 CPIM Subject Header
963 An XMPP presence stanza contains no information that can be mapped to
964 the 'Subject' header of a "Message/CPIM" object. Therefore, if an
965 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
966 PIDF object that contains a 'Subject' header, it SHOULD NOT pass that
967 information on to the XMPP recipient.
969 4.3.6 CPIM Header Extensions
971 "Message/CPIM" objects MAY include an optional 'NS' header to specify
972 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
973 pass such headers through to the XMPP recipient, and no mapping for
974 such headers is defined.
976 4.3.7 CPIM Required Headers
978 "Message/CPIM" objects MAY include an optional 'Required' header to
979 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
980 NOT pass such headers through to the XMPP recipient, and no mapping
981 for such headers is defined.
983 4.3.8 PIDF MIME Content-type
985 As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
986 arbitrary MIME content. However, support for arbitrary content types
987 is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to
988 an XMPP presence stanza a "Message/CPIM" object whose encapsulated
989 MIME object has a Content-type other than "application/pidf+xml"
990 (with the exception of multi-part MIME objects as specified in
991 [XMPP-E2E]).
993 4.3.9 PIDF MIME Content-ID
995 XMPP does not include an element or attribute that captures a
996 globally unique ID as is defined for the Content-ID MIME header as
997 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
998 that includes a Content-ID, it MAY provide the Content-ID as the
999 value of the presence stanza's 'id' attribute but is NOT REQUIRED to
1000 do so.
1002 Example: Content-ID for Encapsulated Object
1004 MIME header
1005 Content-ID: <123456789@example.net>
1007 XMPP 'id' attribute (OPTIONAL)
1008
1009 ...
1010
1012 4.3.10 PIDF Basic Presence Status
1014 The basic presence status types defined in PIDF are OPEN and CLOSED.
1015 The PIDF basic presence status of OPEN maps to an XMPP presence
1016 stanza that possesses no 'type' attribute (indicating default
1017 availability). The PIDF basic presence status of CLOSED maps to an
1018 XMPP presence stanza that possesses a 'type' attribute with a value
1019 of "unavailable".
1021 Example: OPEN Presence
1023 PIDF basic presence (OPEN)
1024
1025
1027
1028
1029 open
1030
1031
1032
1034 XMPP available presence
1035
1037 Example: CLOSED Presence
1039 PIDF basic presence (CLOSED)
1040
1041
1043
1044
1045 closed
1046
1047
1048
1050 XMPP unavailable presence
1051
1054 4.3.11 PIDF Extended Status Information
1056 PIDF documents may contain extended content. As of this
1057 writing there are no pre-defined extended status states that
1058 correspond to the defined values of the XMPP element ('away',
1059 'chat', 'dnd', and 'xa'); as soon as values are specified for
1060 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
1061 namespace, the PIDF values will be mapped to the relevant XMPP
1062 values.
1064 Example: Extended Status Information (provisional)
1066 PIDF extended presence information
1067
1068
1071
1072
1073 open
1074 busy
1075
1076
1077
1079 XMPP element
1080
1081 dnd
1082
1084 4.3.12 PIDF Note Element
1086 A PIDF element may contain a child that provides a
1087 user-defined, natural-language description of the sender's detailed
1088 availability state. The PIDF element maps to the XMPP
1089 element.
1091 Example: Note Element
1093 PIDF element
1094
1095
1098
1099
1100 open
1101 busy
1102
1103 Wooing Juliet
1104
1105
1107 XMPP element
1108
1109 dnd
1110 Wooing Juliet
1111
1113 A PIDF document with zero tuples MAY contain one or more
1114 elements as direct children of the PIDF element. There
1115 is no mapping of such a PIDF document to an XMPP presence stanza; an
1116 entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send
1117 such a PIDF document to an XMPP recipient if possible, and an
1118 XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP
1119 presence stanza (see Zero Resources (Section 5.4.2)).
1121 4.3.13 PIDF Contact Element
1123 The core XMPP specification does not include syntax for specifying
1124 the URL of a contact address, since the contact address is implicit
1125 in the 'from' attribute of the XMPP presence stanza. Therefore, if
1126 an XMPP-CPIM gateway receives a "Message/CPIM" object with
1127 encapsulated PIDF object that contains a element, it
1128 SHOULD NOT pass the XML character data of the element on
1129 to the XMPP recipient. However, the gateway MAY map the 'priority'
1130 element as specified in the following section.
1132 Example: PIDF Contact Element
1134 PIDF element
1135
1136
1138
1139 ...
1140 im:romeo@example.net
1141
1142
1144 XMPP presence stanza
1145
1147 4.3.14 Presence Priority
1149 The child of the PIDF element MAY possess a
1150 'priority' attribute whose value is a decimal number between zero and
1151 one (with a maximum of three decimal places). The value of this
1152 attribute MAY be mapped to the child element of an XMPP
1153 presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
1154 values to negative values of the XMPP element. If an
1155 XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
1156 priority='0' as XMPP 0 and PIDF priority='1' as
1157 127, mapping intermediate values appropriately
1158 so that they are unique (e.g., PIDF priorities between 0.001 and
1159 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to
1160 XMPP priority 2, and so on up through mapping PIDF priorities between
1161 0.992 and 0.999 to XMPP priority 126; note that this is an example
1162 only, and that the exact mapping shall be determined by the XMPP-CPIM
1163 gateway).
1165 4.3.15 PIDF Timestamp Element
1167 The core XMPP specification does not include syntax for specifying
1168 the datetime or timestamp at which a presence stanza was sent.
1169 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1170 with encapsulated PIDF object that contains a element,
1171 it SHOULD NOT pass that information on to the XMPP recipient.
1173 5. XMPP-CPIM Gateway as Presence Service
1175 [CPP] defines semantics for an abstract presence service. An
1176 XMPP-CPIM gateway MAY function as such a presence service, and if so
1177 an XMPP entity can use defined XMPP syntax to interact with the
1178 gateway's presence service. Because [PIDF] does not specify syntax
1179 for semantic operations such as subscribe, this section defines only
1180 the XMPP interactions with the presence service offered by an
1181 XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
1182 (Note: Detailed information about XMPP presence services can be found
1183 in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
1184 implement the syntax, semantics, and server business rules defined
1185 therein.)
1187 5.1 Requesting a Subscription
1189 If an XMPP entity wants to subscribe to the presence information of a
1190 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1191 presence stanza of type "subscribe" to the target presentity. The
1192 syntax mapping is as follows:
1194 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
1195 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
1196 MUST append the "pres:" Presence URI scheme to the front of the
1197 address.
1199 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
1200 "target parameter" field (pres:user@host). The XMPP-CPIM gateway
1201 MUST append the "pres:" Presence URI scheme to the front of the
1202 address.
1204 o There is no XMPP mapping for the CPP "duration parameter", since
1205 XMPP subscriptions are active until they have been explicitly
1206 "unsubscribed" (see Subscription Durations (Section 5.3)).
1208 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1209 field.
1211 If the target presentity approves the subscription request (through
1212 whatever protocol it uses to interact with the gateway), the
1213 XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
1214 to the XMPP entity and notify the XMPP entity of the target's current
1215 available presence. Thereafter, until the subscription is cancelled,
1216 the gateway MUST notify the subscribing XMPP entity every time the
1217 target's presence information changes.
1219 If the target presentity denies the subscription request, the
1220 XMPP-CPIM gateway MUST return a presence stanza of type
1221 "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
1222 operation.
1224 In addition to the approval and denial cases, one of the following
1225 exceptions MAY occur:
1227 o The target parameter (XMPP "to" address) does not refer to a valid
1228 presentity; if this exception occurs, the XMPP-CPIM gateway MUST
1229 return an stanza error to the XMPP entity.
1231 o Access control rules do not permit the entity to subscribe to the
1232 target; if this exception occurs, the XMPP-CPIM gateway MUST
1233 return a stanza error to the XMPP entity.
1235 o There exists a pre-existing subscription or in-progress subscribe
1236 operation between the XMPP entity and the target presentity; if
1237 this exception occurs, the XMPP-CPIM gateway SHOULD return a
1238 stanza error to the XMPP entity.
1240 5.2 Receiving a Subscription Request
1242 If a non-XMPP presentity wants to subscribe to the presence
1243 information of an XMPP entity through an XMPP-CPIM gateway, it MUST
1244 use whatever protocol it uses to interact with the gateway in order
1245 to request the subscription; subject to local access rules, the
1246 gateway MUST then send a presence stanza of type "subscribe" to the
1247 XMPP entity from the non-XMPP watcher. The syntax mapping is as
1248 follows:
1250 o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
1251 to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
1252 MUST remove the "pres:" Presence URI scheme from the front of the
1253 address.
1255 o The CPP "target parameter" field (pres:user@host) MUST be mapped
1256 to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
1257 MUST remove the "pres:" Presence URI scheme from the front of the
1258 address.
1260 o There is no XMPP mapping for the CPP "duration parameter", since
1261 XMPP subscriptions are active until they have been explicitly
1262 "unsubscribed" (see Subscription Durations (Section 5.3)).
1264 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1265 field.
1267 If the target XMPP entity approves the subscription request, it MUST
1268 send a presence stanza of type "subscribed" to the watcher
1269 presentity. The XMPP-CPIM gateway MUST then notify the watcher
1270 presentity of the target XMPP entity's current available presence.
1271 Thereafter, until the subscription is cancelled, the gateway MUST
1272 notify the watcher presentity every time the target's presence
1273 information changes.
1275 If the target XMPP entity denies the subscription request, it MUST
1276 send a presence stanza of type "unsubscribed" to the watcher
1277 presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
1278 operation.
1280 In addition to the approval and denial cases, one of the following
1281 exceptions MAY occur:
1283 o The target parameter (XMPP "to" address) does not refer to a valid
1284 XMPP entity
1286 o Access control rules do not permit the watcher presentity to
1287 subscribe to the target XMPP entity
1289 o There exists a pre-existing subscription or in-progress subscribe
1290 operation between the watcher presentity and the target XMPP
1291 entity
1293 If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
1294 the watcher presentity of failure.
1296 5.3 Subscription Durations
1298 XMPP services assume that a subscription is active until it is
1299 explicitly terminated. With the exception of handling duration
1300 parameters whose value is zero, handling duration parameters will be
1301 highly dependent on the implementation and requirements of the
1302 XMPP-CPIM gateway. Since there are no explicit requirements for
1303 supporting a "duration parameter" specified in either [IMP-MODEL] or
1304 [IMP-REQS], duration parameter mapping is a local issue that falls
1305 outside the scope of this memo.
1307 5.4 The Notify Operation
1309 An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
1310 presence information associated with an XMPP entity or CPP presentity
1311 changes and there are subscribers to that information on the other
1312 side of the gateway. The syntax mapping for presence information
1313 related to a notify operation is defined under Mapping for Presence
1314 (Section 4).
1316 5.4.1 Multiple Resources
1318 Semantically, PIDF contains the notion of multiple presence "tuples".
1319 Normally, a PIDF document will contain at least one tuple but MAY
1320 contain more than one tuple (or zero tuples, for which see next
1321 section). In the terminology of XMPP, each tuple would map to
1322 presence information for a separate resource. However, XMPP does not
1323 include the ability to send presence information about more than one
1324 resource at a time, since the resource that generates the presence
1325 information is contained in the 'from' address of a presence stanza.
1326 Therefore, an XMPP-CPIM gateway that acts as a presence service
1327 SHOULD split a PIDF document that contains multiple tuples into
1328 multiple XMPP presence stanzas, and SHOULD generate only one PIDF
1329 document (with multiple tuples) if an XMPP user currently has
1330 multiple connected resources.
1332 In the interest of not multiplying XMPP stanzas beyond necessity, an
1333 XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the
1334 presence information contained in a PIDF tuple communicates a change
1335 in the availability status of the device or application associated
1336 with that tuple ID.
1338 In the interest of complying with the PIDF recommendation to provide
1339 information about multiple "resources" in multiple tuples rather than
1340 in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
1341 information about all of an XMPP user's resources in one PIDF
1342 document (with one tuple for each resource), even if the availability
1343 status of only one resource has changed.
1345 5.4.2 Zero Resources
1347 A PIDF document may contain zero tuples. For example:
1349 PIDF Document with Zero Tuples
1351
1354 Because (1) the 'entity' attribute of a PIDF element maps
1355 to the portion of an XMPP address and (2) the 'id'
1356 attribute of a PIDF element maps to the resource identifier
1357 portion of an XMPP address, a PIDF document that contains zero tuples
1358 would provide presence information about a rather than a
1359 when mapped to XMPP. However, the notion of
1360 presence about a user rather than a user's resources is meaningless
1361 in the XMPP context. Therefore, an XMPP-CPIM gateway MUST NOT map a
1362 PIDF document with zero tuples into an XMPP presence stanza, and MUST
1363 NOT generate such a PIDF document when receiving a presence stanza
1364 from an XMPP entity (i.e., all PIDF documents generated by the
1365 gateway MUST contain at least one element).
1367 5.5 Unsubscribing
1369 If an XMPP entity wants to unsubscribe from the presence of a
1370 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1371 presence stanza of type "unsubscribe" to the target presentity. The
1372 syntax mapping is as follows:
1374 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
1375 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
1376 MUST append the "pres:" Presence URI scheme to the front of the
1377 address.
1379 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
1380 "target parameter" field (pres:user@host). The XMPP-CPIM gateway
1381 MUST append the "pres:" Presence URI scheme to the front of the
1382 address.
1384 o The CPP "duration parameter" MUST be set to zero.
1386 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1387 field.
1389 If the target parameter (XMPP "to" address) does not refer to a valid
1390 presentity, the XMPP-CPIM gateway MUST return an
1391 stanza error to the XMPP entity.
1393 Upon receiving the presence stanza of type "unsubscribe" from the
1394 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1395 notifications to the XMPP entity.
1397 5.6 Cancelling a Subscription
1399 If an XMPP entity wants to cancel a non-XMPP presentity's
1400 subscription to the entity's presence through an XMPP-CPIM gateway,
1401 it MUST send a presence stanza of type "unsubscribed" to the target
1402 presentity. The syntax mapping is as follows:
1404 o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
1405 to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
1406 MUST remove the "pres:" Presence URI scheme from the front of the
1407 address.
1409 o The CPP "target parameter" field (pres:user@host) MUST be mapped
1410 to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
1411 MUST remove the "pres:" Presence URI scheme from the front of the
1412 address.
1414 o The CPP "duration parameter" MUST be set to zero.
1416 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1417 field.
1419 Upon receiving the presence stanza of type "unsubscribed" from the
1420 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1421 notifications to the watcher presentity.
1423 6. Internationalization Considerations
1425 6.1 Addresses
1427 Although XMPP enables full internationalization of XMPP addresses
1428 (see [XMPP-CORE]), there is no guarantee that non-XMPP addresses can
1429 include characters other than [US-ASCII]. If an XMPP user attempts to
1430 communicate with a non-XMPP user through an XMPP-CPIM gateway, the
1431 XMPP user SHOULD NOT assume that the non-XMPP service supports fully
1432 internationalized addresses.
1434 6.2 Character Encodings
1436 The following rules apply to the mapping of character encodings
1437 (charsets):
1439 1. A gateway SHOULD map a "Message/CPIM" object whose charset is
1440 "US-ASCII" or "UTF-8".
1442 2. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
1443 other than "US-ASCII" or "UTF-8".
1445 7. Security Considerations
1447 Detailed security considerations for instant messaging and presence
1448 protocols are given in [IMP-REQS], specifically in Sections 5.1
1449 through 5.4.
1451 This document specifies methods for exchanging instant messages and
1452 presence information through a gateway that implements [CPIM] and
1453 [CPP]. Such a gateway MUST be compliant with the minimum security
1454 requirements of the instant messaging and presence protocols with
1455 which it interfaces. The introduction of gateways to the security
1456 model of instant messaging and presence in RFC 2779 also introduces
1457 some new risks. In particular, end-to-end security properties
1458 (especially confidentiality and integrity) between instant messaging
1459 and presence user agents that interface through an XMPP-CPIM gateway
1460 can be provided only if common formats are supported; these formats
1461 are specified fully in [XMPP-E2E].
1463 Normative References
1465 [CPIM] Peterson, J., "Common Profile for Instant Messaging
1466 (CPIM)", draft-ietf-impp-im-04 (work in progress), August
1467 2003.
1469 [CPP] Peterson, J., "Common Profile for Presence (CPP)",
1470 draft-ietf-impp-pres-04 (work in progress), August 2003.
1472 [IMP-MODEL]
1473 Day, M., Rosenberg, J. and H. Sugano, "A Model for
1474 Presence and Instant Messaging", RFC 2778, February 2000,
1475 .
1477 [IMP-REQS]
1478 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
1479 Presence Protocol Requirements", RFC 2779, February 2000.
1481 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1482 Extensions (MIME) Part One: Format of Internet Message
1483 Bodies", RFC 2045, November 1996.
1485 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
1486 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08
1487 (work in progress), January 2003.
1489 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
1490 and J. Peterson, "CPIM Presence Information Data Format",
1491 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
1493 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
1494 Requirement Levels", BCP 14, RFC 2119, March 1997.
1496 [US-ASCII]
1497 Cerf, V., "ASCII format for network interchange", RFC 20,
1498 October 1969.
1500 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
1501 10646", RFC 2279, January 1998.
1503 [XMPP-CORE]
1504 Saint-Andre (ed.), P., "Extensible Messaging and Presence
1505 Protocol (XMPP): Core", draft-ietf-xmpp-core-20 (work in
1506 progress), November 2003.
1508 [XMPP-E2E]
1509 Saint-Andre (ed.), P., "End-to-End Object Encryption in
1510 the Extensible Messaging and Presence Protocol (XMPP)",
1511 draft-ietf-xmpp-e2e-06 (work in progress), November 2003.
1513 [XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence
1514 Protocol (XMPP): Instant Messaging and Presence",
1515 draft-ietf-xmpp-im-19 (work in progress), November 2003.
1517 Informative References
1519 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
1520 2001.
1522 [MIMETYPES]
1523 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1524 Extensions (MIME) Part Two: Media Types", RFC 2046,
1525 November 1996.
1527 Author's Address
1529 Peter Saint-Andre
1530 Jabber Software Foundation
1532 EMail: stpeter@jabber.org
1534 Appendix A. Revision History
1536 Note to RFC Editor: please remove this entire appendix, and the
1537 corresponding entries in the table of contents, prior to publication.
1539 A.1 Changes from draft-ietf-xmpp-cpim-02
1541 o Removed references to UTF-16.
1543 o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data.
1545 o Added information about internationalization of addresses.
1547 o Completed formatting changes to meet RFC Editor requirements.
1549 A.2 Changes from draft-ietf-xmpp-cpim-01
1551 o Added subsection about handling presence notifications for
1552 multiple XMPP resources and multiple PIDF tuples.
1554 o Added subsection about PIDF documents that contain zero tuples.
1556 o Further specified mapping between XMPP addresses and CPIM instant
1557 inboxes and presentities.
1559 A.3 Changes from draft-ietf-xmpp-cpim-00
1561 o Updated references.
1563 o Made several small editorial changes.
1565 Intellectual Property Statement
1567 The IETF takes no position regarding the validity or scope of any
1568 intellectual property or other rights that might be claimed to
1569 pertain to the implementation or use of the technology described in
1570 this document or the extent to which any license under such rights
1571 might or might not be available; neither does it represent that it
1572 has made any effort to identify any such rights. Information on the
1573 IETF's procedures with respect to rights in standards-track and
1574 standards-related documentation can be found in BCP-11. Copies of
1575 claims of rights made available for publication and any assurances of
1576 licenses to be made available, or the result of an attempt made to
1577 obtain a general license or permission for the use of such
1578 proprietary rights by implementors or users of this specification can
1579 be obtained from the IETF Secretariat.
1581 The IETF invites any interested party to bring to its attention any
1582 copyrights, patents or patent applications, or other proprietary
1583 rights which may cover technology that may be required to practice
1584 this standard. Please address the information to the IETF Executive
1585 Director.
1587 Full Copyright Statement
1589 Copyright (C) The Internet Society (2003). All Rights Reserved.
1591 This document and translations of it may be copied and furnished to
1592 others, and derivative works that comment on or otherwise explain it
1593 or assist in its implementation may be prepared, copied, published
1594 and distributed, in whole or in part, without restriction of any
1595 kind, provided that the above copyright notice and this paragraph are
1596 included on all such copies and derivative works. However, this
1597 document itself may not be modified in any way, such as by removing
1598 the copyright notice or references to the Internet Society or other
1599 Internet organizations, except as needed for the purpose of
1600 developing Internet standards in which case the procedures for
1601 copyrights defined in the Internet Standards process must be
1602 followed, or as required to translate it into languages other than
1603 English.
1605 The limited permissions granted above are perpetual and will not be
1606 revoked by the Internet Society or its successors or assignees.
1608 This document and the information contained herein is provided on an
1609 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1610 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1611 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1612 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1613 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1615 Acknowledgment
1617 Funding for the RFC Editor function is currently provided by the
1618 Internet Society.