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