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