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