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