idnits 2.17.1
draft-ietf-xmpp-cpim-04.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 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 (March 8, 2004) is 7348 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 3454 (ref. 'STRINGPREP') (Obsoleted by
RFC 7564)
** Obsolete normative reference: RFC 2718 (ref. 'URL-GUIDE') (Obsoleted by
RFC 4395)
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
== Outdated reference: A later version (-24) exists of
draft-ietf-xmpp-core-22
== Outdated reference: A later version (-09) exists of
draft-ietf-xmpp-e2e-07
== Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-21
-- Obsolete informational reference (is this intentional?): RFC 2822
(Obsoleted by RFC 5322)
== Outdated reference: A later version (-03) exists of
draft-saintandre-xmpp-pidf-00
Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XMPP Working Group P. Saint-Andre
3 Internet-Draft Jabber Software Foundation
4 Expires: September 6, 2004 March 8, 2004
6 Mapping the Extensible Messaging and Presence Protocol (XMPP) to
7 Common Presence and Instant Messaging (CPIM)
8 draft-ietf-xmpp-cpim-04
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that other
17 groups may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at http://
25 www.ietf.org/ietf/1id-abstracts.txt.
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 This Internet-Draft will expire on September 6, 2004.
32 Copyright Notice
34 Copyright (C) The Internet Society (2004). All Rights Reserved.
36 Abstract
38 This memo describes a mapping of the Extensible Messaging and
39 Presence Protocol (XMPP) to the Common Presence and Instant Messaging
40 (CPIM) specifications.
42 Table of Contents
44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
45 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
46 3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5
47 4. Syntax Mapping of Instant Messages . . . . . . . . . . . . . . 6
48 5. Syntax Mapping of Presence Information . . . . . . . . . . . . 13
49 6. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26
50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
51 Normative References . . . . . . . . . . . . . . . . . . . . . 31
52 Informative References . . . . . . . . . . . . . . . . . . . . 33
53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
54 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 33
55 Intellectual Property and Copyright Statements . . . . . . . . 35
57 1. Introduction
59 1.1 Overview
61 The Instant Messaging and Presence (IMPP) Working Group has defined
62 an abstract framework for interoperability among instant messaging
63 (IM) and presence systems that are compliant with [IMP-REQS]. This
64 framework is commonly called Common Presence and Instant Messaging or
65 "CPIM". The CPIM family of specifications include a Common Profile
66 for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
67 Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
68 Information Data Format [PIDF]. (Note: To prevent confusion, Common
69 Presence and Instant Messaging is referred to herein collectively as
70 "the CPIM specifications", whereas the Common Profile for Instant
71 Messaging is referred to as "CPIM".)
73 This memo describes how the Extensible Messaging and Presence
74 Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
75 contained in the CPIM specifications, mainly for the purpose of
76 establishing gateways between XMPP services and non-XMPP services
77 that conform to [IMP-REQS]. Such a gateway, referred to herein as an
78 "XMPP-CPIM gateway", may be established to interpret the protocols of
79 one service and translate them into the protocols of the other
80 service. We can visualize this relationship as follows:
82 +-------------+ +-------------+ +------------+
83 | | | | | |
84 | XMPP | | XMPP-CPIM | | Non-XMPP |
85 | Service | <----> | Gateway | <----> | Service |
86 | | | | | |
87 +-------------+ +-------------+ +------------+
89 This memo defines a mapping for use by a gateway that translates
90 between XMPP and a non-XMPP protocol via the CPIM specifications.
91 Such a gateway is not an intermediate hop on a network of non-XMPP
92 servers (whose native formats may or may not be defined by the CPIM
93 specifications), but a dedicated translator between XMPP and a
94 non-XMPP protocol, where the CPIM specifications define the common
95 formats into which the protocols are translated for purposes of
96 interworking.
98 The mapping defined herein applies to instant messages and presence
99 information that are not encrypted or signed for end-to-end security.
100 For information about secure communications to or from an XMPP
101 service through an XMPP-CPIM gateway, refer to [XMPP-E2E].
103 1.2 Terminology
105 This memo inherits vocabulary defined in [IMP-MODEL]. Terms such as
106 CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
107 PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
108 defined therein.
110 This memo also inherits vocabulary defined in [XMPP-CORE]. Terms
111 such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
112 IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
113 meaning as defined therein.
115 1.3 Conventions Used in this Document
117 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
118 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
119 "OPTIONAL" in this document are to be interpreted as described in
120 [TERMS].
122 1.4 Discussion Venue
124 The author welcomes discussion and comments related to the topics
125 presented in this document. The preferred forum is the
126 mailing list, for which archives and subscription
127 information are available at <>.
130 2. Approach
132 XMPP and CPIM are distinctly foreign technologies. Therefore, care
133 must be taken in mapping between XMPP and the abstract syntax defined
134 by the CPIM specifications.
136 At root, XMPP is a data transport protocol for streaming XML elements
137 (called "stanzas") between any two endpoints on the network; message
138 and presence stanzas are two of the core data elements defined in
139 XMPP and are often used to exchange instant messages and presence
140 information between IM users (although the inherent extensibility of
141 XML enables applications to use the general semantics of these stanza
142 types for other purposes). XMPP is not based on [MIME]; instead,
143 [XMPP-CORE] defines XML schemas for both message and presence stanzas
144 (for example, the child of a message stanza contains XML
145 character data that is usually intended to be read by a human user).
147 The CPIM specifications provide common formats for instant messaging
148 and presence through two [MIME] content-types: "Message/CPIM" for
149 messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]).
150 The syntax of "Message/CPIM" objects is similar to but stricter than
151 that defined in [RFC2822], and provides the ability to include
152 arbitrary MIME media types [MIMETYPES]. By contrast, each
153 "application/pidf+xml" object is a complete XML document whose
154 structure is defined by an XML schema.
156 The approach taken herein is to specify mappings from XMPP elements
157 and attributes to the headers and MIME formats defined by [MSGFMT]
158 and [PIDF] in order to comply with the semantics defined by [CPIM]
159 and [CPP]. Naturally, mappings in the opposite direction are
160 provided as well.
162 3. Address Mapping
164 3.1 Overview
166 Address mapping may be required since the address formats used to
167 identify XMPP entities (specified in [XMPP-CORE]) are different from
168 those used to identify instant inboxes (the im: URI scheme specified
169 in [CPIM]) and presentitites (the pres: URI scheme specified in
170 [CPP]). In particular, different characters are allowed in im: and
171 pres: URIs than are allowed in XMPP addresses:
173 o The following [US-ASCII] characters are allowed in im:/pres: URIs
174 but not in XMPP addresses: #26; (&), #27; ('), and #2f; (/).
175 o Many non-US-ASCII (specifically, UTF-8) characters are allowed in
176 XMPP addresses but not allowed in im:/pres: URIs, since XMPP
177 allows internationalized local-part addresses.
179 Note: In this document we discuss characters allowed in local-part
180 addresses only (i.e., we have ruled the mapping of domain names as
181 out of scope for the initial version of this document, since it is a
182 matter for the Domain Name System and the translation of fully
183 internationalized domain names).
185 3.2 XMPP to CPIM
187 The following is a high-level algorithm for mapping an XMPP address
188 to an im: or pres: URI:
190 1. Split XMPP address into node identifier (local-part; mapping
191 described in remaining steps), domain identifier (hostname;
192 mapping is out of scope), and resource identifier (specifier for
193 particular device or connection; discard this for cross-system
194 interoperability)
195 2. Apply Nodeprep profile of [STRINGPREP] (as specified in
196 [XMPP-CORE]) for canonicalization (OPTIONAL)
197 3. Translate #26; to &, #27; to ', and #2f; to / respectively
198 4. For each byte, if the byte is not in the set -A-Za-z0-9!$*.?_~+=
199 then change to %hexhex as described in Section 2.2.5 of
200 [URL-GUIDE]
201 5. Combine resulting local-part with mapped hostname to form
202 local@domain address
203 6. Prepend with 'im:' scheme (for XMPP stanzas) or
204 'pres:' scheme (for XMPP stanzas)
206 3.3 CPIM to XMPP
208 The following is a high-level algorithm for mapping an im: or pres:
209 URI to an XMPP address:
211 1. Remove URI scheme
212 2. Split at the first '@' character into local-part and hostname
213 (mapping the latter is out of scope)
214 3. Translate %hexhex to equivalent octets as described in Section
215 2.2.5 of [URL-GUIDE]
216 4. Treat result as a UTF-8 string
217 5. Translate & to #26;, ' to #27;, and / to @2f respectively
218 6. Apply Nodeprep profile of [STRINGPREP] (as specified in
219 [XMPP-CORE]) for canonicalization (OPTIONAL)
220 7. Recombine local-part with mapped hostname to form local@domain
221 address
223 4. Syntax Mapping of Instant Messages
225 This section describes how a gateway SHOULD map instant messages
226 between an XMPP service and a non-XMPP service using a "Message/CPIM"
227 object as the bearer of encapsulated text content in order to comply
228 with the instant messaging semantics defined by [CPIM].
230 4.1 Message Syntax Mapping from XMPP to CPIM Specifications
232 This section defines the mapping of syntax primitives from XMPP
233 message stanzas to "Message/CPIM" objects with encapsulated text
234 content.
236 Note: As specified in [MIME], the default Content-type of a MIME
237 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
238 uses the [UTF-8] character encoding exclusively, the encapsulated
239 MIME object generated by an XMPP-CPIM gateway MUST set the
240 'Content-type' header for that object. Specifically, the
241 "Content-type" MUST be set to "text/plain" and the charset MUST be
242 set to "utf-8".
244 4.1.1 From Address
246 The 'from' attribute of an XMPP message stanza maps to the 'From'
247 header of a "Message/CPIM" object. In XMPP, the sender's server
248 stamps or validates the "from" address and sets its value to the full
249 negotiated between client and server during
250 authentication and resource binding as defined in [XMPP-CORE]. Thus
251 an XMPP-CPIM gateway will receive from the sender's XMPP server a
252 message stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP message stanza to
254 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
255 the resource identifier, MUST append the "im:" Instant Messaging URI
256 scheme to the front of the address, and MAY include a CPIM
257 "Formal-name" for the sender (if known).
259 Example: From Address Mapping
261 XMPP 'from' attribute
262
263 ...
264
266 CPIM 'From' header
267 From: Juliet Capulet
269 4.1.2 To Address
271 The 'to' attribute of an XMPP message stanza maps to the 'To' header
272 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a
273 'to' attribute on a message stanza, and MUST include it if the
274 message is intended for delivery to another user. Thus an XMPP-CPIM
275 gateway will receive from the sender's XMPP server a message stanza
276 containing a "to" address of the form or . To map the 'to' attribute of an XMPP message stanza to
278 the 'To' header of a "Message/CPIM" object, the gateway MUST remove
279 the resource identifier (if included), MUST append the "im:" Instant
280 Messaging URI scheme to the front of the address, and MAY include a
281 CPIM "Formal-name" for the recipient (if known).
283 Example: To Address Mapping
285 XMPP 'to' attribute
286
287 ...
288
290 CPIM 'To' header
291 To: Romeo Montague
293 4.1.3 Stanza ID
295 An XMPP message stanza MAY possess an 'id' attribute, which is used
296 by the sending application for the purpose of tracking stanzas and is
297 not a globally-unique identifier such as is defined by the MIME
298 Content-ID header. Because the XMPP 'id' attribute does not have the
299 same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
300 to that header; however, if the 'id' is known to be unique (e.g., if
301 it is generated to be unique by the XMPP server and that fact is
302 known by the XMPP-CPIM gateway), then it SHOULD be so mapped.
304 4.1.4 Message Type
306 An XMPP message stanza MAY possess a 'type' attribute, which is used
307 by the sending application to capture the conversational context of
308 the message. There is no mapping of an XMPP 'type' attribute to a
309 "Message/CPIM" header, common MIME features, or encapsulated text
310 content. Therefore if an XMPP stanza received by an XMPP-CPIM
311 gateway possesses a 'type' attribute, the gateway SHOULD ignore the
312 value provided.
314 4.1.5 Message Thread
316 An XMPP message stanza MAY contain a child element to
317 specify the conversation thread in which the message is situated.
318 There is no mapping of an XMPP element to a "Message/CPIM"
319 header, common MIME features, or encapsulated text content.
320 Therefore if an XMPP message stanza received by an XMPP-CPIM gateway
321 contains a child element, the gateway SHOULD ignore the
322 value provided.
324 4.1.6 Message Subject
326 An XMPP message stanza MAY include a child element. If
327 included, it maps to the 'Subject' header of a "Message/CPIM" object.
328 To map the XMPP element to the 'Subject' header of a
329 "Message/CPIM" object, the gateway SHOULD simply map the XML
330 character data of the XMPP element to the value of the
331 'Subject' header. The element MAY include an 'xml:lang'
332 attribute specifying the language in which the subject is written.
333 If an 'xml:lang' attribute is provided, it MUST be mapped by
334 including ';lang=tag' after the header name and colon, where 'tag' is
335 the value of the 'xml:lang' attribute.
337 Example: Subject Mapping
339 XMPP element
340 Hi!
341 Ahoj!
343 CPIM 'Subject' header
344 Subject: Hi!
345 Subject:;lang=cz Ahoj!
347 4.1.7 Message Body
349 The child element of an XMPP message stanza is used to
350 provide the primary meaning of the message. The XML character data
351 of the XMPP element maps to the encapsulated text message
352 content.
354 Example: Message Body
356 XMPP message
357
358 Wherefore art thou, Romeo?
359
361 Encapsulated MIME text content
362 Content-type: text/plain; charset=utf-8
363 Content-ID: <123456789@example.net>
365 Wherefore art thou, Romeo?
367 4.1.8 Message Extensions
369 As defined in [XMPP-CORE], an XMPP message stanza may contain
370 "extended" content in any namespace in order to supplement or extend
371 the semantics of the core message stanza. With the exception of
372 extended information qualified by the
373 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
374 an XMPP-CPIM gateway SHOULD ignore such information and not pass it
375 through the gateway to the intended recipient. No mapping for such
376 information is defined.
378 4.1.9 Gateway-Generated CPIM Syntax
380 CPIM specifies the existence of "Message/CPIM" headers in addition to
381 those described above, but there is no exact analogue for those
382 headers in the core XMPP specifications. These include:
384 o cc -- specifies the address of an entity that is to receive a
385 "courtesy copy" of the message (i.e., a non-primary addressee)
386 o DateTime -- specifies the datetime at which the message was sent
387 o NS -- specifies the namespace of a feature extension
388 o Required -- specifies mandatory-to-recognize features
390 An XMPP-CPIM gateway MAY independently generate such headers based on
391 its own information (e.g., the datetime at which it received a
392 message stanza from an XMPP entity) or based on data encoded in
393 non-core XMPP extensions, but rules for doing so are out of scope for
394 this memo.
396 4.2 Message Syntax Mapping from CPIM Specifications to XMPP
398 This section defines the mapping of syntax primitives from "Message/
399 CPIM" objects with encapsualted text content to XMPP message stanzas.
401 4.2.1 From Address
403 The 'From' header of a "Message/CPIM" object maps to the 'from'
404 attribute of an XMPP message stanza. To map the CPIM 'From' header
405 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
406 Instant Messaging URI scheme from the front of the address and MUST
407 remove the CPIM "Formal-name" (if provided).
409 Example: From Address Mapping
411 CPIM 'From' header
412 From: Romeo Montague
414 XMPP 'from' attribute
415
416 ...
417
419 4.2.2 To Address
421 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
422 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP
423 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
424 URI scheme from the front of the address and MUST remove the CPIM
425 "Formal-name" (if provided). If the gateway possesses knowledge of
426 the resource identifier in use by the XMPP entity, the gateway MAY
427 append the resource identifier to the address.
429 Example: To Address Mapping
431 CPIM 'To' header
432 To: Juliet Capulet
434 XMPP 'to' attribute
435
436 ...
437
439 4.2.3 Courtesy Copy
441 The core XMPP specification does not include syntax for specifying a
442 "courtesy copy" (non-primary addressee) for a message stanza.
443 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
444 that contains a 'cc' header, it SHOULD NOT pass that information on
445 to the XMPP recipient.
447 4.2.4 DateTime Header
449 The core XMPP specification does not include syntax for specifying
450 the datetime at which a message stanza was sent. Therefore, if an
451 XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
452 'DateTime' header, it SHOULD NOT pass that information on to the XMPP
453 recipient.
455 4.2.5 Message Subject
457 The 'Subject' header of a "Message/CPIM" object maps to the child element of an XMPP message stanza. To map the CPIM 'Subject'
459 header to the XMPP element, the gateway SHOULD simply map
460 the value of the 'Subject' header to the XML character data of the
461 XMPP element. The 'Subject' header MAY specify the "lang"
462 in which the subject is written. If "lang" information is provided,
463 it MUST be mapped to the 'xml:lang' attribute of the
464 element, where the value of the 'xml:lang' attribute is the the "tag"
465 value supplied in the string ';lang=tag' included CPIM 'Subject'
466 header name and colon.
468 Example: Subject Mapping
470 CPIM 'Subject' header
471 Subject: Hi!
472 Subject:;lang=cz Ahoj!
474 XMPP element
475 Hi!
476 Ahoj!
478 4.2.6 Header Extensions
480 "Message/CPIM" objects MAY include an optional 'NS' header to specify
481 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
482 pass such headers through to the XMPP recipient, and no mapping for
483 such headers is defined.
485 4.2.7 Required Headers
487 "Message/CPIM" objects MAY include an optional 'Required' header to
488 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
489 NOT pass such headers through to the XMPP recipient, and no mapping
490 for such headers is defined.
492 4.2.8 MIME Content-ID
494 XMPP does not include an element or attribute that captures a
495 globally unique ID as is defined for the Content-ID MIME header as
496 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
497 that includes a Content-ID, it MAY provide the Content-ID as the
498 value of the message stanza's 'id' attribute, but this is OPTIONAL.
500 Example: Content-ID for Encapsulated Object
502 MIME header
503 Content-ID: <123456789@example.net>
505 XMPP 'id' attribute (OPTIONAL)
506
507 ...
508
510 4.2.9 Message Body
512 If the Content-type of an encapsulated MIME object is "text/plain",
513 then the encapsulated text message content maps to the XML character
514 data of the child element of an XMPP message stanza.
516 Example: Message Body
518 Encapsulated MIME text content
519 Content-type: text/plain; charset=utf-8
520 Content-ID: <123456789@example.net>
522 Wherefore art thou?
524 XMPP message
525
526 Wherefore art thou?
527
529 If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY
530 map the content to an XMPP extension but MUST NOT map it to the
531 child of the XMPP message stanza, which is allowed to contain
532 XML character data only. The only exception to this rule is a
533 multi-part MIME object of the kind specified in [XMPP-E2E], which is
534 to be mapped as described in that memo.
536 If the charset is "US-ASCII" or "UTF-8", the gateway SHOULD map the
537 "Message/CPIM" object; otherwise it SHOULD NOT.
539 4.2.10 Gateway-Generated XMPP Syntax
541 XMPP specifies the existence of a 'type' attribute for XMPP message
542 stanzas, which enables the sender to define the conversational
543 context of the message. There is no exact analogue for this
544 attribute in CPIM. An XMPP-CPIM gateway MAY independently generate
545 the 'type' attribute based on its own information, but this is
546 OPTIONAL and rules for doing so are out of scope for this memo.
548 5. Syntax Mapping of Presence Information
550 This section describes how a gateway SHOULD map presence information
551 between an XMPP service and a non-XMPP service using a "Message/CPIM"
552 object as the bearer of an encapsulated [PIDF] object in order to
553 comply with the presence semantics defined by [CPP].
555 5.1 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 Note: As specified in [MIME], the default Content-type of a MIME
562 object is "Content-type: text/plain; charset=us-ascii". Because XMPP
563 uses the [UTF-8] character encoding exclusively and because PIDF
564 specifies the "application/pidf+xml" MIME type, the encapsulated MIME
565 object generated by an XMPP-CPIM gateway for presence information
566 MUST set the 'Content-type' header for that object. The
567 "Content-type" MUST be set to "application/pidf+xml" and the charset
568 MUST be set to "utf-8".
570 5.1.1 From Address
572 The 'from' attribute of an XMPP presence stanza maps to the 'From'
573 header of a "Message/CPIM" object. In XMPP, the sender's server
574 stamps or validates the "from" address and sets its value to the
575 negotiated between client and server during
576 authenticating and resource binding as defined in [XMPP-CORE]. Thus
577 an XMPP-CPIM gateway will receive from the sender's XMPP server a
578 presence stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP presence stanza to
580 the 'From' header of a "Message/CPIM" object, the gateway MUST remove
581 the resource identifier, MUST append the "im:" Instant Messaging URI
582 scheme to the front of the address, and MAY include a CPIM
583 "Formal-name" for the sender (if known).
585 Example: From Address Mapping
587 XMPP 'from' attribute
588
589 ...
590
592 CPIM 'From' header
593 From: Juliet Capulet
595 In addition, the 'from' attribute of an XMPP presence stanza maps to
596 the 'entity' attribute of a PIDF root element. To map
597 the XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
598 MUST remove the resource identifier and MUST append the "pres:"
599 Instant Messaging URI scheme to the front of the address.
601 Example: From Address Mapping (PIDF)
603 XMPP 'from' attribute
604
605 ...
606
608 PIDF 'entity' attribute
609
610 ...
611
613 Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
614 the XMPP address contained in the XMPP 'from' attribute to the 'id'
615 attribute of the PIDF child element.
617 Example: Resource Identifier Mapping
619 XMPP 'from' attribute
620
621 ...
622
624 PIDF 'id' for
625
626
627 ...
628
629
631 5.1.2 To Address
633 The 'to' attribute of an XMPP presence stanza maps to the 'To' header
634 of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to'
635 attribute on a presence stanza, and MUST include it if the presence
636 stanza is intended for delivery directly to another user (presence
637 stanzas intended for broadcasting are stamped with a 'to' address by
638 the sender's server). Thus an XMPP-CPIM gateway will receive from
639 the sender's XMPP server a presence stanza containing a "to" address
640 of the form or . To map the 'to'
641 attribute of an XMPP presence stanza to the 'To' header of a
642 "Message/CPIM" object, the gateway MUST remove the resource
643 identifier (if included), MUST append the "im:" Instant Messaging URI
644 scheme to the front of the address, and MAY include a CPIM
645 "Formal-name" for the recipient (if known).
647 Example: To Address Mapping
649 XMPP 'to' attribute
650
651 ...
652
654 CPIM 'To' header
655 To: Romeo Montague
657 5.1.3 Stanza ID
659 An XMPP presence stanza MAY possess an 'id' attribute, which is used
660 by the sending application for the purpose of tracking stanzas and is
661 not a globally-unique identifier such as is defined by the MIME
662 Content-ID header. Because the XMPP 'id' attribute does not have the
663 same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
664 to that header; however, if the 'id' is known to be unique (e.g., if
665 it is generated to be unique by the XMPP server and that fact is
666 known by the XMPP-CPIM gateway), then it SHOULD be so mapped.
668 5.1.4 Presence Type
670 An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
671 attribute is included, the presence stanza indicates that the sender
672 is available; this state maps to the PIDF basic presence type of
673 OPEN. If the 'type' attribute has a value of "unavailable", the
674 presence stanza indicates that the sender is no longer available;
675 this state maps to the PIDF basic presence type of CLOSED. Thus both
676 the absence of a 'type' attribute and a 'type' attribute set to a
677 value of "unavailable" correspond to the [CPP] "notify operation".
678 All other presence types are used to manage presence subscriptions or
679 probe for current presence; mappings for these other presence types
680 are defined under XMPP-CPIM Gateway as Presence Service (Section 6).
682 Example: Available Presence
684 XMPP available presence
685
687 PIDF basic presence (OPEN)
688
689
691
692
693 open
694
695
696
698 Example: Unavailable Presence
700 XMPP unavailable presence
701
703 PIDF basic presence (CLOSED)
704
705
707
708
709 closed
710
711
712
714 5.1.5 Show Element
716 The child element of an XMPP presence stanza provides
717 additional information about the sender's availability. The XML
718 character data of the XMPP element maps to extended
719 content in PIDF. The defined values of the element are
720 'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for
721 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
722 namespace, the XMPP values will be mapped to the PIDF values.
724 Example: Show Element
726 XMPP element
727
728 away
729
731 PIDF extended presence information
732
733
736
737
738 open
739 away
740
741
742
744 5.1.6 Status Element
746 The child element of an XMPP presence stanza provides a
747 user-defined, natural-language description of the sender's detailed
748 availability state. The XMPP element maps to the PIDF
749 child of the PIDF element.
751 Example: Status Element
753 XMPP element
754
755 away
756 retired to the chamber
757
759 PIDF element
760
761
764
765
766 open
767 away
768
769 retired to the chamber
770
771
773 5.1.7 Presence Priority
775 An XMPP presence stanza MAY contain a child element whose
776 value is an integer between -128 and +127. The value of this element
777 MAY be mapped to the 'priority' attribute of the child of
778 the PIDF element. If the value of the XMPP
779 element is negative, an XMPP-CPIM gateway MUST NOT map the value.
780 The range of allowable values for the PIDF 'priority' attribute is
781 any decimal number from zero to one inclusive, with a maximum of
782 three decimal places. If an XMPP-CPIM gateway maps these values, it
783 SHOULD treat XMPP 0 as PIDF priority='0' and
784 XMPP 127 as PIDF priority='1', mapping
785 intermediate values appropriately so that they are unique (e.g., XMPP
786 priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority
787 0.015, and so on up through mapping XMPP priority 126 to PIDF
788 priority 0.992; note that this is an example only, and that the exact
789 mapping shall be determined by the XMPP-CPIM gateway).
791 Example: Presence Priority
793 XMPP element
794
795 13
796
798 PIDF element
799
800
802
803 ...
804 im:juliet@example.com
805
806
808 5.1.8 Presence Extensions
810 As defined in [XMPP-CORE], an XMPP presence stanza may contain
811 "extended" content in any namespace in order to supplement or extend
812 the semantics of the core presence stanza. With the exception of
813 extended information qualified by the
814 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
815 an XMPP-CPIM gateway SHOULD ignore such information and not pass it
816 through the gateway to the intended recipient. No mapping for such
817 information is defined.
819 5.1.9 Gateway-Generated CPIM and PIDF Syntax
821 5.1.9.1 CPIM Message Headers
823 CPIM specifies the existence of "Message/CPIM" headers in addition to
824 those described above, but there is no exact analogue for those
825 headers in the core XMPP specifications. These include:
827 o cc -- specifies the address of an entity that is to receive a
828 "courtesy copy" of the presence information (i.e., a non-primary
829 addressee)
830 o DateTime -- specifies the datetime at which the presence
831 information was sent
832 o NS -- specifies the namespace of a feature extension
833 o Subject -- specifies the subject or topic of the encapsulated
834 "Message/CPIM" object
835 o Required -- specifies mandatory-to-recognize features
837 An XMPP-CPIM gateway MAY independently generate such headers based on
838 its own information (e.g., the datetime at which it received a
839 presence stanza from an XMPP entity) or based on data encoded in
840 non-core XMPP extensions, but rules for doing so are out of scope for
841 this memo.
843 5.1.9.2 PIDF Elements
845 PIDF specifies the existence of XML elements in addition to those
846 described above, but there is no exact analogue for those XML
847 elements in the core XMPP specifications. These include:
849 o -- specifies an address (e.g., an im:, tel:, or mailto:
850 URI) at which one may communicate with the presentity; an
851 XMPP-CPIM gateway MAY include this element, in which case it
852 SHOULD set its value to the of the XMPP sender,
853 prepended by the "im:" Instant Messaging URI scheme.
854 o -- specifies the datetime at which the presence
855 information was sent; an XMPP-CPIM gateway MAY independently
856 generate this element based on its own information (e.g., the
857 datetime at which it received the presence stanza from an XMPP
858 entity) or based on data encoded in non-core XMPP extensions, but
859 rules for doing so are out of scope for this memo.
861 5.2 Presence Syntax Mapping from CPIM Specifications to XMPP
863 This section defines the mapping of syntax primitives from "Message/
864 CPIM" objects with encapsulated "application/pidf+xml" objects to
865 XMPP presence stanzas.
867 Note: An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a
868 "Message/CPIM" object whose encapsulated MIME object has a
869 Content-type other than "application/pidf+xml" (with the exception of
870 multi-part MIME objects as specified in [XMPP-E2E]).
872 5.2.1 From Address
874 The 'From' header of a "Message/CPIM" object maps to the 'from'
875 attribute of an XMPP presence stanza. To map the CPIM 'From' header
876 to the XMPP 'from' attribute, the gateway MUST remove the "im:"
877 Instant Messaging URI scheme from the front of the address and MUST
878 remove the CPIM "Formal-name" (if provided).
880 Example: From Address Mapping
882 CPIM 'From' header
883 From: Romeo Montague
885 XMPP 'from' attribute
886
887 ...
888
890 5.2.2 To Address
892 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
893 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
894 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
895 URI scheme from the front of the address and MUST remove the CPIM
896 "Formal-name" (if provided). If the gateway possesses knowledge of
897 the resource identifier in use by the XMPP entity, the gateway MAY
898 append the resource identifier to the address.
900 Example: To Address Mapping
902 CPIM 'To' header
903 To: Juliet Capulet
905 XMPP 'to' attribute
906
907 ...
908
910 5.2.3 Courtesy Copy
912 The core XMPP specification does not include syntax for specifying a
913 "courtesy copy" (non-primary addressee) for a presence stanza.
914 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
915 with encapsulated PIDF object that contains a 'cc' header, it SHOULD
916 NOT pass that information on to the XMPP recipient.
918 5.2.4 DateTime Header
920 The core XMPP specification does not include syntax for specifying
921 the datetime at which a presence stanza was sent. Therefore, if an
922 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
923 PIDF object that contains a 'DateTime' header, it SHOULD NOT pass
924 that information on to the XMPP recipient.
926 5.2.5 Subject Header
928 An XMPP presence stanza contains no information that can be mapped to
929 the 'Subject' header of a "Message/CPIM" object. Therefore, if an
930 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
931 PIDF object that contains a 'Subject' header, it SHOULD NOT pass that
932 information on to the XMPP recipient.
934 5.2.6 Header Extensions
936 "Message/CPIM" objects MAY include an optional 'NS' header to specify
937 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
938 pass such headers through to the XMPP recipient, and no mapping for
939 such headers is defined.
941 5.2.7 Required Headers
943 "Message/CPIM" objects MAY include an optional 'Required' header to
944 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
945 NOT pass such headers through to the XMPP recipient, and no mapping
946 for such headers is defined.
948 5.2.8 MIME Content-ID
950 XMPP does not include an element or attribute that captures a
951 globally unique ID as is defined for the Content-ID MIME header as
952 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
953 that includes a Content-ID, it MAY provide the Content-ID as the
954 value of the presence stanza's 'id' attribute, but this is OPTIONAL.
956 Example: Content-ID for Encapsulated Object
958 MIME header
959 Content-ID: <123456789@example.net>
961 XMPP 'id' attribute (OPTIONAL)
962
963 ...
964
966 5.2.9 Basic Presence Status
968 The basic presence status types defined in PIDF are OPEN and CLOSED.
969 The PIDF basic presence status of OPEN maps to an XMPP presence
970 stanza that possesses no 'type' attribute (indicating default
971 availability). The PIDF basic presence status of CLOSED maps to an
972 XMPP presence stanza that possesses a 'type' attribute with a value
973 of "unavailable".
975 Example: OPEN Presence
977 PIDF basic presence (OPEN)
978
979
981
982
983 open
984
985
986
988 XMPP available presence
989
991 Example: CLOSED Presence
993 PIDF basic presence (CLOSED)
994
995
997
998
999 closed
1000
1001
1002
1004 XMPP unavailable presence
1005
1008 5.2.10 Extended Status Information
1010 PIDF documents may contain extended content. As of this
1011 writing there are no pre-defined extended status states that
1012 correspond to the defined values of the XMPP element ('away',
1013 'chat', 'dnd', and 'xa'); as soon as values are specified for
1014 extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
1015 namespace, the PIDF values will be mapped to the relevant XMPP
1016 values.
1018 Example: Extended Status Information (provisional)
1020 PIDF extended presence information
1021
1022
1025
1026
1027 open
1028 busy
1029
1030
1031
1033 XMPP element
1034
1035 dnd
1036
1038 5.2.11 Note Element
1040 A PIDF element may contain a child that provides a
1041 user-defined, natural-language description of the sender's detailed
1042 availability state. The PIDF element maps to the XMPP
1043 element.
1045 Example: Note Element
1047 PIDF element
1048
1049
1052
1053
1054 open
1055 busy
1056
1057 Wooing Juliet
1058
1059
1061 XMPP element
1062
1063 dnd
1064 Wooing Juliet
1066
1068 A PIDF document with zero tuples MAY contain one or more
1069 elements as direct children of the PIDF element. There
1070 is no mapping of such a PIDF document to an XMPP presence stanza; an
1071 entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send
1072 such a PIDF document to an XMPP recipient if possible, and an
1073 XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP
1074 presence stanza (see Zero Resources (Section 6.3.2)).
1076 5.2.12 Contact Element
1078 A PIDF document may contain a element specifying the URI
1079 of an address at which the principal can be contacted (e.g., an im:,
1080 tel:, or mailto: URI). The core XMPP specification does not include
1081 syntax for specifying the URI of a contact address, since the contact
1082 address is implicit in the 'from' attribute of the XMPP presence
1083 stanza. Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM"
1084 object with encapsulated PIDF object that contains a
1085 element, it SHOULD NOT pass the XML character data of the
1086 element on to the XMPP recipient. (However, see Inclusion of
1087 Complete PIDF Document (Section 5.2.15) below.)
1089 Example: PIDF Contact Element
1091 PIDF element
1092
1093
1095
1096 ...
1097 im:romeo@example.net
1098
1099
1101 XMPP presence stanza
1102
1104 5.2.13 Presence Priority
1106 The child of the PIDF element MAY possess a
1107 'priority' attribute whose value is a decimal number between zero and
1108 one (with a maximum of three decimal places). The value of this
1109 attribute MAY be mapped to the child element of an XMPP
1110 presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
1111 values to negative values of the XMPP element. If an
1112 XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
1113 priority='0' as XMPP 0 and PIDF priority='1' as
1114 127, mapping intermediate values appropriately
1115 so that they are unique (e.g., PIDF priorities between 0.001 and
1116 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to
1117 XMPP priority 2, and so on up through mapping PIDF priorities between
1118 0.992 and 0.999 to XMPP priority 126; note that this is an example
1119 only, and that the exact mapping shall be determined by the XMPP-CPIM
1120 gateway).
1122 5.2.14 Timestamp Element
1124 The core XMPP specification does not include syntax for specifying
1125 the datetime or timestamp at which a presence stanza was sent.
1126 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
1127 with encapsulated PIDF object that contains a element,
1128 it SHOULD NOT pass that information on to the XMPP recipient.
1130 5.2.15 Inclusion of Complete PIDF Document
1132 Certain PIDF elements do not map to XMPP presence stanza syntax
1133 (e.g., the XML character data of the element). However,
1134 an XMPP client may be able to handle such information by parsing a
1135 native PIDF document. To make this possible, an XMPP-CPIM gateway
1136 MAY include the complete PIDF document as a child element of the
1137 presence stanza, as described in [XMPP-PIDF]. If an XMPP client does
1138 not understand this extended data, it naturally MUST ignore it.
1140 6. XMPP-CPIM Gateway as Presence Service
1142 [CPP] defines semantics for an abstract presence service. An
1143 XMPP-CPIM gateway MAY function as such a presence service, and if so
1144 an XMPP entity can use defined XMPP syntax to interact with the
1145 gateway's presence service. Because [PIDF] does not specify syntax
1146 for semantic operations such as subscribe, this section defines only
1147 the XMPP interactions with the presence service offered by an
1148 XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
1149 (Note: Detailed information about XMPP presence services can be found
1150 in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
1151 implement the syntax, semantics, and server business rules defined
1152 therein.)
1154 6.1 Requesting a Subscription
1156 If an XMPP entity wants to subscribe to the presence information of a
1157 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1158 presence stanza of type "subscribe" to the target presentity. The
1159 syntax mapping is as follows:
1161 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
1162 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
1163 MUST append the "pres:" Presence URI scheme to the front of the
1164 address.
1165 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
1166 "target parameter" field (pres:user@host). The XMPP-CPIM gateway
1167 MUST append the "pres:" Presence URI scheme to the front of the
1168 address.
1169 o There is no XMPP mapping for the CPP "duration parameter", since
1170 XMPP subscriptions are active until they have been explicitly
1171 "unsubscribed".
1172 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1173 field.
1175 If the target presentity approves the subscription request (through
1176 whatever protocol it uses to interact with the gateway), the
1177 XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
1178 to the XMPP entity and notify the XMPP entity of the target's current
1179 available presence. Thereafter, until the subscription is cancelled,
1180 the gateway MUST notify the subscribing XMPP entity every time the
1181 target's presence information changes.
1183 If the target presentity denies the subscription request, the
1184 XMPP-CPIM gateway MUST return a presence stanza of type
1185 "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
1186 operation.
1188 In addition to the approval and denial cases, one of the following
1189 exceptions may occur:
1191 o The target parameter (XMPP "to" address) does not refer to a valid
1192 presentity; if this exception occurs, the XMPP-CPIM gateway MUST
1193 return an stanza error to the XMPP entity.
1194 o Access control rules do not permit the entity to subscribe to the
1195 target; if this exception occurs, the XMPP-CPIM gateway MUST
1196 return a stanza error to the XMPP entity.
1197 o There exists a pre-existing subscription or in-progress subscribe
1198 operation between the XMPP entity and the target presentity; if
1199 this exception occurs, the XMPP-CPIM gateway SHOULD return a
1200 stanza error to the XMPP entity.
1202 6.2 Receiving a Subscription Request
1204 If a non-XMPP presentity wants to subscribe to the presence
1205 information of an XMPP entity through an XMPP-CPIM gateway, it MUST
1206 use whatever protocol it uses to interact with the gateway in order
1207 to request the subscription; subject to local access rules, the
1208 gateway MUST then send a presence stanza of type "subscribe" to the
1209 XMPP entity from the non-XMPP watcher. The syntax mapping is as
1210 follows:
1212 o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
1213 to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
1214 MUST remove the "pres:" Presence URI scheme from the front of the
1215 address.
1216 o The CPP "target parameter" field (pres:user@host) MUST be mapped
1217 to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
1218 MUST remove the "pres:" Presence URI scheme from the front of the
1219 address.
1220 o There is no XMPP mapping for the CPP "duration parameter", since
1221 XMPP subscriptions are active until they have been explicitly
1222 "unsubscribed".
1223 o The CPP "TransID" field SHOULD be mapped to the XMPP 'id'
1224 attribute.
1226 If the target XMPP entity approves the subscription request, it MUST
1227 send a presence stanza of type "subscribed" to the watcher
1228 presentity. The XMPP-CPIM gateway MUST then notify the watcher
1229 presentity of the target XMPP entity's current available presence.
1230 Thereafter, until the subscription is cancelled, the gateway MUST
1231 notify the watcher presentity every time the target's presence
1232 information changes.
1234 If the target XMPP entity denies the subscription request, it MUST
1235 send a presence stanza of type "unsubscribed" to the watcher
1236 presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
1237 operation.
1239 In addition to the approval and denial cases, one of the following
1240 exceptions MAY occur:
1242 o The target parameter (XMPP "to" address) does not refer to a valid
1243 XMPP entity
1244 o Access control rules do not permit the watcher presentity to
1245 subscribe to the target XMPP entity
1246 o There exists a pre-existing subscription or in-progress subscribe
1247 operation between the watcher presentity and the target XMPP
1248 entity
1250 If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
1251 the watcher presentity of failure.
1253 XMPP services assume that a subscription is active until it is
1254 explicitly terminated. With the exception of handling duration
1255 parameters whose value is zero, handling duration parameters will be
1256 highly dependent on the implementation and requirements of the
1257 XMPP-CPIM gateway. Since there are no explicit requirements for
1258 supporting a "duration parameter" specified in either [IMP-MODEL] or
1259 [IMP-REQS], duration parameter mapping is a local issue that falls
1260 outside the scope of this memo. However, an XMPP-CPIM gateway MAY
1261 keep track of the duration parameter if received from an entity on
1262 the non-XMPP service and delete the subscription after that duration
1263 parameter expires.
1265 6.3 The Notify Operation
1267 An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
1268 presence information associated with an XMPP entity or CPP presentity
1269 changes and there are subscribers to that information on the other
1270 side of the gateway. The syntax mapping for presence information
1271 related to a notify operation is defined under Mapping for Presence
1272 (Section 5).
1274 6.3.1 Multiple Resources
1276 Semantically, PIDF contains the notion of multiple presence "tuples".
1277 Normally, a PIDF document will contain at least one tuple but MAY
1278 contain more than one tuple (or zero tuples, for which see next
1279 section). In the terminology of XMPP, each tuple would map to
1280 presence information for a separate resource. However, XMPP does not
1281 include the ability to send presence information about more than one
1282 resource at a time, since the resource that generates the presence
1283 information is contained in the 'from' address of a presence stanza.
1284 Therefore, an XMPP-CPIM gateway that acts as a presence service
1285 SHOULD split a PIDF document that contains multiple tuples into
1286 multiple XMPP presence stanzas, and SHOULD generate only one PIDF
1287 document (with multiple tuples) if an XMPP user currently has
1288 multiple connected resources.
1290 In the interest of not multiplying XMPP stanzas beyond necessity, an
1291 XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the
1292 presence information contained in a PIDF tuple communicates a change
1293 in the availability status of the device or application associated
1294 with that tuple ID.
1296 In the interest of complying with the PIDF recommendation to provide
1297 information about multiple "resources" in multiple tuples rather than
1298 in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
1299 information about all of an XMPP user's resources in one PIDF
1300 document (with one tuple for each resource), even if the availability
1301 status of only one resource has changed.
1303 6.3.2 Zero Resources
1305 A PIDF document may contain zero tuples. For example:
1307 PIDF Document with Zero Tuples
1309
1312 Because (1) the 'entity' attribute of a PIDF element maps
1313 to the portion of an XMPP address and (2) the 'id'
1314 attribute of a PIDF element maps to the resource identifier
1315 portion of an XMPP address, a PIDF document that contains zero tuples
1316 would provide presence information about a rather than a
1317 when mapped to XMPP. Although the notion of
1318 presence notifications about a mere user rather than one of the
1319 user's resources is nearly meaningless in the XMPP context, an
1320 XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an
1321 XMPP presence stanza whose 'from' address is the user@host of the
1322 non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a
1323 PIDF document with zero children when receiving a presence
1324 stanza from an XMPP entity (i.e., all PIDF documents communicated by
1325 the gateway to a non-XMPP service MUST contain at least one
1326 element).
1328 6.4 Unsubscribing
1330 If an XMPP entity wants to unsubscribe from the presence of a
1331 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
1332 presence stanza of type "unsubscribe" to the target presentity. The
1333 syntax mapping is as follows:
1335 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
1336 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
1337 MUST append the "pres:" Presence URI scheme to the front of the
1338 address.
1339 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
1340 "target parameter" field (pres:user@host). The XMPP-CPIM gateway
1341 MUST append the "pres:" Presence URI scheme to the front of the
1342 address.
1343 o The CPP "duration parameter" MUST be set to zero.
1344 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1345 field.
1347 If the target parameter (XMPP "to" address) does not refer to a valid
1348 presentity, the XMPP-CPIM gateway MUST return an
1349 stanza error to the XMPP entity.
1351 Upon receiving the presence stanza of type "unsubscribe" from the
1352 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1353 notifications to the XMPP entity.
1355 6.5 Cancelling a Subscription
1357 If an XMPP entity wants to cancel a non-XMPP presentity's
1358 subscription to the entity's presence through an XMPP-CPIM gateway,
1359 it MUST send a presence stanza of type "unsubscribed" to the target
1360 presentity. The syntax mapping is as follows:
1362 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
1363 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
1364 MUST add the "pres:" Presence URI scheme to the front of the
1365 address.
1366 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
1367 "target parameter" field (pres:user@host). The XMPP-CPIM gateway
1368 MUST add the "pres:" Presence URI scheme to the front of the
1369 address.
1370 o The CPP "duration parameter" MUST be set to zero.
1371 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
1372 field.
1374 Upon receiving the presence stanza of type "unsubscribed" from the
1375 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
1376 notifications to the watcher presentity.
1378 7. Security Considerations
1380 Detailed security considerations for instant messaging and presence
1381 protocols are given in [IMP-REQS], specifically in Sections 5.1
1382 through 5.4.
1384 This document specifies methods for exchanging instant messages and
1385 presence information through a gateway that implements [CPIM] and
1386 [CPP]. Such a gateway MUST be compliant with the minimum security
1387 requirements of the instant messaging and presence protocols with
1388 which it interfaces. The introduction of gateways to the security
1389 model of instant messaging and presence in RFC 2779 also introduces
1390 some new risks. In particular, end-to-end security properties
1391 (especially confidentiality and integrity) between instant messaging
1392 and presence user agents that interface through an XMPP-CPIM gateway
1393 can be provided only if common formats are supported; these formats
1394 are specified fully in [XMPP-E2E].
1396 Normative References
1398 [CPIM] Peterson, J., "Common Profile for Instant Messaging
1399 (CPIM)", draft-ietf-impp-im-04 (work in progress), August
1400 2003.
1402 [CPP] Peterson, J., "Common Profile for Presence (CPP)",
1403 draft-ietf-impp-pres-04 (work in progress), August 2003.
1405 [IMP-MODEL]
1406 Day, M., Rosenberg, J. and H. Sugano, "A Model for
1407 Presence and Instant Messaging", RFC 2778, February 2000,
1408 .
1410 [IMP-REQS]
1411 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
1412 Presence Protocol Requirements", RFC 2779, February 2000.
1414 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1415 Extensions (MIME) Part One: Format of Internet Message
1416 Bodies", RFC 2045, November 1996.
1418 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
1419 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08
1420 (work in progress), January 2003.
1422 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
1423 and J. Peterson, "CPIM Presence Information Data Format",
1424 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
1426 [STRINGPREP]
1427 Hoffman, P. and M. Blanchet, "Preparation of
1428 Internationalized Strings ("STRINGPREP")", RFC 3454,
1429 December 2002.
1431 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
1432 Requirement Levels", BCP 14, RFC 2119, March 1997.
1434 [URL-GUIDE]
1435 Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
1436 "Guidelines for new URL Schemes", RFC 2718, November 1999.
1438 [US-ASCII]
1439 Cerf, V., "ASCII format for network interchange", RFC 20,
1440 October 1969.
1442 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
1443 10646", RFC 2279, January 1998.
1445 [XMPP-CORE]
1446 Saint-Andre (ed.), P., "Extensible Messaging and Presence
1447 Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in
1448 progress), January 2004.
1450 [XMPP-E2E]
1451 Saint-Andre (ed.), P., "End-to-End Object Encryption in
1452 the Extensible Messaging and Presence Protocol (XMPP)",
1453 draft-ietf-xmpp-e2e-07 (work in progress), December 2003.
1455 [XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence
1456 Protocol (XMPP): Instant Messaging and Presence",
1457 draft-ietf-xmpp-im-21 (work in progress), January 2004.
1459 Informative References
1461 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
1462 2001.
1464 [MIMETYPES]
1465 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1466 Extensions (MIME) Part Two: Media Types", RFC 2046,
1467 November 1996.
1469 [XMPP-PIDF]
1470 Saint-Andre, P., "Transporting Presence Information Data
1471 Format (PIDF) over the Extensible Messaging and Presence
1472 Protocol (XMPP)", draft-saintandre-xmpp-pidf-00 (work in
1473 progress), February 2004.
1475 Author's Address
1477 Peter Saint-Andre
1478 Jabber Software Foundation
1480 EMail: stpeter@jabber.org
1482 Appendix A. Revision History
1484 Note to RFC Editor: please remove this entire appendix, and the
1485 corresponding entries in the table of contents, prior to publication.
1487 A.1 Changes from draft-ietf-xmpp-cpim-03
1489 o Addressed feedback from WG Chairs.
1491 A.2 Changes from draft-ietf-xmpp-cpim-02
1492 o Removed references to UTF-16.
1493 o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data.
1494 o Added information about internationalization of addresses.
1495 o Completed formatting changes to meet RFC Editor requirements.
1497 A.3 Changes from draft-ietf-xmpp-cpim-01
1499 o Added subsection about handling presence notifications for
1500 multiple XMPP resources and multiple PIDF tuples.
1501 o Added subsection about PIDF documents that contain zero tuples.
1502 o Further specified mapping between XMPP addresses and CPIM instant
1503 inboxes and presentities.
1505 A.4 Changes from draft-ietf-xmpp-cpim-00
1507 o Updated references.
1508 o Made several small editorial changes.
1510 Intellectual Property Statement
1512 The IETF takes no position regarding the validity or scope of any
1513 intellectual property or other rights that might be claimed to
1514 pertain to the implementation or use of the technology described in
1515 this document or the extent to which any license under such rights
1516 might or might not be available; neither does it represent that it
1517 has made any effort to identify any such rights. Information on the
1518 IETF's procedures with respect to rights in standards-track and
1519 standards-related documentation can be found in BCP-11. Copies of
1520 claims of rights made available for publication and any assurances of
1521 licenses to be made available, or the result of an attempt made to
1522 obtain a general license or permission for the use of such
1523 proprietary rights by implementors or users of this specification can
1524 be obtained from the IETF Secretariat.
1526 The IETF invites any interested party to bring to its attention any
1527 copyrights, patents or patent applications, or other proprietary
1528 rights which may cover technology that may be required to practice
1529 this standard. Please address the information to the IETF Executive
1530 Director.
1532 Full Copyright Statement
1534 Copyright (C) The Internet Society (2004). All Rights Reserved.
1536 This document and translations of it may be copied and furnished to
1537 others, and derivative works that comment on or otherwise explain it
1538 or assist in its implementation may be prepared, copied, published
1539 and distributed, in whole or in part, without restriction of any
1540 kind, provided that the above copyright notice and this paragraph are
1541 included on all such copies and derivative works. However, this
1542 document itself may not be modified in any way, such as by removing
1543 the copyright notice or references to the Internet Society or other
1544 Internet organizations, except as needed for the purpose of
1545 developing Internet standards in which case the procedures for
1546 copyrights defined in the Internet Standards process must be
1547 followed, or as required to translate it into languages other than
1548 English.
1550 The limited permissions granted above are perpetual and will not be
1551 revoked by the Internet Society or its successors or assignees.
1553 This document and the information contained herein is provided on an
1554 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1555 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1556 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1557 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1558 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1560 Acknowledgment
1562 Funding for the RFC Editor function is currently provided by the
1563 Internet Society.