idnits 2.17.1 draft-ietf-xmpp-cpim-05.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 == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 10) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages 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 (May 3, 2004) is 7297 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) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-23 == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-e2e-07 -- 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: 6 errors (**), 0 flaws (~~), 8 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: November 1, 2004 May 3, 2004 6 Mapping the Extensible Messaging and Presence Protocol (XMPP) to 7 Common Presence and Instant Messaging (CPIM) 8 draft-ietf-xmpp-cpim-05 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 November 1, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This memo describes a mapping between the Extensible Messaging and 39 Presence Protocol (XMPP) and the Common Presence and Instant 40 Messaging (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 . . . . . . . . . . . . 27 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 51 Normative References . . . . . . . . . . . . . . . . . . . . . 32 52 Informative References . . . . . . . . . . . . . . . . . . . . 34 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34 54 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 34 55 Intellectual Property and Copyright Statements . . . . . . . . 36 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 2. Approach 124 XMPP and CPIM are distinctly foreign technologies. Therefore, care 125 must be taken in mapping between XMPP and the abstract syntax defined 126 by the CPIM specifications. 128 At root, XMPP is a data transport protocol for streaming XML elements 129 (called "stanzas") between any two endpoints on the network; message 130 and presence stanzas are two of the core data elements defined in 131 XMPP and are often used to exchange instant messages and presence 132 information between IM users (although the inherent extensibility of 133 XML enables applications to use the general semantics of these stanza 134 types for other purposes). XMPP is not based on [MIME]; instead, 135 [XMPP-CORE] defines XML schemas for both message and presence stanzas 136 (for example, the child of a message stanza contains XML 137 character data that is usually intended to be read by a human user). 139 The CPIM specifications provide common formats for instant messaging 140 and presence through two [MIME] content-types: "Message/CPIM" for 141 messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]). 142 The syntax of "Message/CPIM" objects is similar to but stricter than 143 that defined in [RFC2822], and provides the ability to include 144 arbitrary MIME media types [MIMETYPES]. By contrast, each 145 "application/pidf+xml" object is a complete XML document whose 146 structure is defined by an XML schema. 148 The approach taken herein is to specify mappings from XMPP elements 149 and attributes to the headers and MIME formats defined by [MSGFMT] 150 and [PIDF] in order to comply with the semantics defined by [CPIM] 151 and [CPP]. Naturally, mappings in the opposite direction are 152 provided as well. 154 3. Address Mapping 156 3.1 Overview 158 Address mapping may be required since the address formats used to 159 identify XMPP entities (specified in [XMPP-CORE]) are different from 160 those used to identify instant inboxes (the im: URI scheme specified 161 in [CPIM]) and presentitites (the pres: URI scheme specified in 162 [CPP]). In particular, different characters are allowed in im: and 163 pres: URIs than are allowed in XMPP addresses: 165 o The following [US-ASCII] characters are allowed in im:/pres: URIs 166 but not in XMPP addresses: #26; (&), #27; ('), and #2f; (/). 167 o Many non-US-ASCII (specifically, UTF-8) characters are allowed in 168 XMPP addresses but not allowed in im:/pres: URIs, since XMPP 169 allows internationalized local-part addresses. 171 Note: In this document we discuss characters allowed in local-part 172 addresses only (i.e., we have ruled the mapping of domain names as 173 out of scope for the initial version of this document, since it is a 174 matter for the Domain Name System and the translation of fully 175 internationalized domain names). 177 3.2 XMPP to CPIM 179 The following is a high-level algorithm for mapping an XMPP address 180 to an im: or pres: URI: 182 1. Split XMPP address into node identifier (local-part; mapping 183 described in remaining steps), domain identifier (hostname; 184 mapping is out of scope), and resource identifier (specifier for 185 particular device or connection; discard this for cross-system 186 interoperability) 187 2. Apply Nodeprep profile of [STRINGPREP] (as specified in 188 [XMPP-CORE]) for canonicalization (OPTIONAL) 189 3. Translate #26; to &, #27; to ', and #2f; to / respectively 190 4. For each byte, if the byte is not in the set A-Za-z0-9!$*.?_~+= 191 then change to %hexhex as described in Section 2.2.5 of 192 [URL-GUIDE] 193 5. Combine resulting local-part with mapped hostname to form 194 local@domain address 195 6. Prepend with 'im:' scheme (for XMPP stanzas) or 196 'pres:' scheme (for XMPP stanzas) 198 3.3 CPIM to XMPP 200 The following is a high-level algorithm for mapping an im: or pres: 201 URI to an XMPP address: 203 1. Remove URI scheme 204 2. Split at the first '@' character into local-part and hostname 205 (mapping the latter is out of scope) 206 3. Translate %hexhex to equivalent octets as described in Section 207 2.2.5 of [URL-GUIDE] 208 4. Treat result as a UTF-8 string 209 5. Translate & to #26;, ' to #27;, and / to #2f respectively 210 6. Apply Nodeprep profile of [STRINGPREP] (as specified in 211 [XMPP-CORE]) for canonicalization (OPTIONAL) 212 7. Recombine local-part with mapped hostname to form local@domain 213 address 215 4. Syntax Mapping of Instant Messages 217 This section describes how a gateway SHOULD map instant messages 218 between an XMPP service and a non-XMPP service using a "Message/CPIM" 219 object as the bearer of encapsulated text content in order to comply 220 with the instant messaging semantics defined by [CPIM]. 222 4.1 Message Syntax Mapping from XMPP to CPIM Specifications 224 This section defines the mapping of syntax primitives from XMPP 225 message stanzas to "Message/CPIM" objects with encapsulated text 226 content. 228 Note: As specified in [MIME], the default Content-type of a MIME 229 object is "Content-type: text/plain; charset=us-ascii". Because XMPP 230 uses the [UTF-8] character encoding exclusively, the encapsulated 231 MIME object generated by an XMPP-CPIM gateway MUST set the 232 'Content-type' header for that object. Specifically, the 233 "Content-type" MUST be set to "text/plain" and the charset MUST be 234 set to "utf-8". 236 4.1.1 From Address 238 The 'from' attribute of an XMPP message stanza maps to the 'From' 239 header of a "Message/CPIM" object. In XMPP, the sender's server 240 stamps or validates the "from" address and sets its value to the full 241 negotiated between client and server during 242 authentication and resource binding as defined in [XMPP-CORE]. Thus 243 an XMPP-CPIM gateway will receive from the sender's XMPP server a 244 message stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP message stanza to 246 the 'From' header of a "Message/CPIM" object, the gateway MUST remove 247 the resource identifier, MUST append the "im:" Instant Messaging URI 248 scheme to the front of the address, and MAY include a CPIM 249 "Formal-name" for the sender (if known). 251 Example: From Address Mapping 253 XMPP 'from' attribute 254 255 ... 256 258 CPIM 'From' header 259 From: Juliet Capulet 261 4.1.2 To Address 263 The 'to' attribute of an XMPP message stanza maps to the 'To' header 264 of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 265 'to' attribute on a message stanza, and MUST include it if the 266 message is intended for delivery to another user. Thus an XMPP-CPIM 267 gateway will receive from the sender's XMPP server a message stanza 268 containing a "to" address of the form or . To map the 'to' attribute of an XMPP message stanza to 270 the 'To' header of a "Message/CPIM" object, the gateway MUST remove 271 the resource identifier (if included), MUST append the "im:" Instant 272 Messaging URI scheme to the front of the address, and MAY include a 273 CPIM "Formal-name" for the recipient (if known). 275 Example: To Address Mapping 277 XMPP 'to' attribute 278 279 ... 280 282 CPIM 'To' header 283 To: Romeo Montague 285 4.1.3 Stanza ID 287 An XMPP message stanza MAY possess an 'id' attribute, which is used 288 by the sending application for the purpose of tracking stanzas and is 289 not a globally-unique identifier such as is defined by the MIME 290 Content-ID header. Because the XMPP 'id' attribute does not have the 291 same meaning as the MIME Content-ID header, it SHOULD NOT be mapped 292 to that header; however, if the 'id' is known to be unique (e.g., if 293 it is generated to be unique by the XMPP server and that fact is 294 known by the XMPP-CPIM gateway), then it SHOULD be so mapped. 296 4.1.4 Message Type 298 An XMPP message stanza MAY possess a 'type' attribute, which is used 299 by the sending application to capture the conversational context of 300 the message. There is no mapping of an XMPP 'type' attribute to a 301 "Message/CPIM" header, common MIME features, or encapsulated text 302 content. Therefore if an XMPP stanza received by an XMPP-CPIM 303 gateway possesses a 'type' attribute, the gateway SHOULD ignore the 304 value provided. 306 4.1.5 Message Thread 308 An XMPP message stanza MAY contain a child element to 309 specify the conversation thread in which the message is situated. 310 There is no mapping of an XMPP element to a "Message/CPIM" 311 header, common MIME features, or encapsulated text content. 312 Therefore if an XMPP message stanza received by an XMPP-CPIM gateway 313 contains a child element, the gateway SHOULD ignore the 314 value provided. 316 4.1.6 Message Subject 318 An XMPP message stanza MAY include a child element. If 319 included, it maps to the 'Subject' header of a "Message/CPIM" object. 320 To map the XMPP element to the 'Subject' header of a 321 "Message/CPIM" object, the gateway SHOULD simply map the XML 322 character data of the XMPP element to the value of the 323 'Subject' header. The element MAY include an 'xml:lang' 324 attribute specifying the language in which the subject is written. 325 If an 'xml:lang' attribute is provided, it MUST be mapped by 326 including ';lang=tag' after the header name and colon, where 'tag' is 327 the value of the 'xml:lang' attribute. 329 Example: Subject Mapping 331 XMPP element 332 Hi! 333 Ahoj! 335 CPIM 'Subject' header 336 Subject: Hi! 337 Subject:;lang=cz Ahoj! 339 4.1.7 Message Body 341 The child element of an XMPP message stanza is used to 342 provide the primary meaning of the message. The XML character data 343 of the XMPP element maps to the encapsulated text message 344 content. 346 Example: Message Body 348 XMPP message 349 350 Wherefore art thou, Romeo? 351 353 Encapsulated MIME text content 354 Content-type: text/plain; charset=utf-8 355 Content-ID: <123456789@example.net> 357 Wherefore art thou, Romeo? 359 4.1.8 Message Extensions 361 As defined in [XMPP-CORE], an XMPP message stanza may contain 362 "extended" content in any namespace in order to supplement or extend 363 the semantics of the core message stanza. With the exception of 364 extended information qualified by the 365 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E], 366 an XMPP-CPIM gateway SHOULD ignore such information and not pass it 367 through the gateway to the intended recipient. No mapping for such 368 information is defined. 370 4.1.9 Gateway-Generated CPIM Syntax 372 CPIM specifies the existence of "Message/CPIM" headers in addition to 373 those described above, but there is no exact analogue for those 374 headers in the core XMPP specifications. These include: 376 o cc -- specifies the address of an entity that is to receive a 377 "courtesy copy" of the message (i.e., a non-primary addressee) 378 o DateTime -- specifies the datetime at which the message was sent 379 o NS -- specifies the namespace of a feature extension 380 o Require -- specifies mandatory-to-recognize features 382 An XMPP-CPIM gateway MAY independently generate such headers based on 383 its own information (e.g., the datetime at which it received a 384 message stanza from an XMPP entity) or based on data encoded in 385 non-core XMPP extensions, but rules for doing so are out of scope for 386 this memo. 388 4.2 Message Syntax Mapping from CPIM Specifications to XMPP 390 This section defines the mapping of syntax primitives from "Message/ 391 CPIM" objects with encapsualted text content to XMPP message stanzas. 393 4.2.1 From Address 395 The 'From' header of a "Message/CPIM" object maps to the 'from' 396 attribute of an XMPP message stanza. To map the CPIM 'From' header 397 to the XMPP 'from' attribute, the gateway MUST remove the "im:" 398 Instant Messaging URI scheme from the front of the address and MUST 399 remove the CPIM "Formal-name" (if provided). 401 Example: From Address Mapping 403 CPIM 'From' header 404 From: Romeo Montague 406 XMPP 'from' attribute 407 408 ... 409 411 4.2.2 To Address 413 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute 414 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP 415 'to' attribute, the gateway MUST remove the "im:" Instant Messaging 416 URI scheme from the front of the address and MUST remove the CPIM 417 "Formal-name" (if provided). If the gateway possesses knowledge of 418 the resource identifier in use by the XMPP entity, the gateway MAY 419 append the resource identifier to the address. 421 Example: To Address Mapping 423 CPIM 'To' header 424 To: Juliet Capulet 426 XMPP 'to' attribute 427 428 ... 429 431 4.2.3 Courtesy Copy 433 The core XMPP specification does not include syntax for specifying a 434 "courtesy copy" (non-primary addressee) for a message stanza. 435 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object 436 that contains a 'cc' header, it SHOULD NOT pass the information 437 contained in that header on to the XMPP recipient. 439 4.2.4 DateTime Header 441 The core XMPP specification does not include syntax for specifying 442 the datetime at which a message stanza was sent. Therefore, if an 443 XMPP-CPIM gateway receives a "Message/CPIM" object that contains a 444 'DateTime' header, it SHOULD NOT pass the information contained in 445 that header on to the XMPP recipient. 447 4.2.5 Message Subject 449 The 'Subject' header of a "Message/CPIM" object maps to the child element of an XMPP message stanza. To map the CPIM 'Subject' 451 header to the XMPP element, the gateway SHOULD simply map 452 the value of the 'Subject' header to the XML character data of the 453 XMPP element. The 'Subject' header MAY specify the "lang" 454 in which the subject is written. If "lang" information is provided, 455 it MUST be mapped to the 'xml:lang' attribute of the 456 element, where the value of the 'xml:lang' attribute is the the "tag" 457 value supplied in the string ';lang=tag' included CPIM 'Subject' 458 header name and colon. 460 Example: Subject Mapping 462 CPIM 'Subject' header 463 Subject: Hi! 464 Subject:;lang=cz Ahoj! 466 XMPP element 467 Hi! 468 Ahoj! 470 4.2.6 Header Extensions 472 "Message/CPIM" objects MAY include an optional 'NS' header to specify 473 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT 474 pass such headers through to the XMPP recipient, and no mapping for 475 such headers is defined. 477 4.2.7 Require Header 479 "Message/CPIM" objects MAY include an optional 'Require' header to 480 specify mandatory-to-recognize features. In general, such a header 481 would be included by the non-XMPP sending application to (1) insist 482 that the receiving application needs to understand functionality 483 specified by a particular header or (2) indicate that some non-header 484 semantics need to be implemented by the receiving application in 485 order to understand the contents of the message (e.g., 486 "Locale.MustRenderKanji"). Because the mandatory-to-recognize 487 features would be required of the XMPP receiving application rather 488 than the XMPP-CPIM gateway itself, the gateway cannot properly handle 489 the 'Require' header without detailed knowledge about the 490 capabilities of the XMPP receiving application. Therefore, it seems 491 appropriate that the XMPP-CPIM gateway SHOULD return a warning or 492 error to the non-XMPP sending application if it includes one or more 493 'Require' headers in a "Message/CPIM" object; the exact nature of the 494 warning or error will depend on the nature of the non-XMPP technology 495 used by the foreign system, and is not defined herein. Furthermore, 496 any mapping of the 'Require' header into XMPP or an XMPP extension is 497 left up to the implementation or to a future specification. 499 4.2.8 MIME Content-ID 501 XMPP does not include an element or attribute that captures a 502 globally unique ID as is defined for the Content-ID MIME header as 503 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object 504 that includes a Content-ID, it MAY provide the Content-ID as the 505 value of the message stanza's 'id' attribute, but this is OPTIONAL. 507 Example: Content-ID for Encapsulated Object 509 MIME header 510 Content-ID: <123456789@example.net> 512 XMPP 'id' attribute (OPTIONAL) 513 514 ... 515 517 4.2.9 Message Body 519 If the Content-type of an encapsulated MIME object is "text/plain", 520 then the encapsulated text message content maps to the XML character 521 data of the child element of an XMPP message stanza. 523 Example: Message Body 525 Encapsulated MIME text content 526 Content-type: text/plain; charset=utf-8 527 Content-ID: <123456789@example.net> 529 Wherefore art thou? 531 XMPP message 532 533 Wherefore art thou? 534 536 If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY 537 map the content to an XMPP extension but MUST NOT map it to the 538 child of the XMPP message stanza, which is allowed to contain 539 XML character data only. The only exception to this rule is a 540 multi-part MIME object of the kind specified in [XMPP-E2E], which is 541 to be mapped as described in that memo. 543 If the charset is "US-ASCII" or "UTF-8", the gateway MUST map the 544 "Message/CPIM" object; otherwise it SHOULD NOT. 546 4.2.10 Gateway-Generated XMPP Syntax 548 XMPP specifies the existence of a 'type' attribute for XMPP message 549 stanzas, which enables the sender to define the conversational 550 context of the message. There is no exact analogue for this 551 attribute in CPIM. An XMPP-CPIM gateway MAY independently generate 552 the 'type' attribute based on its own information, but this is 553 OPTIONAL and rules for doing so are out of scope for this memo. 555 5. Syntax Mapping of Presence Information 557 This section describes how a gateway SHOULD map presence information 558 between an XMPP service and a non-XMPP service using a "Message/CPIM" 559 object as the bearer of an encapsulated [PIDF] object in order to 560 comply with the presence semantics defined by [CPP]. 562 5.1 Presence Syntax Mapping from XMPP to CPIM Specifications 564 This section defines the mapping of syntax primitives from XMPP 565 presence stanzas to "Message/CPIM" objects with encapsulated 566 "application/pidf+xml" objects. 568 Note: As specified in [MIME], the default Content-type of a MIME 569 object is "Content-type: text/plain; charset=us-ascii". Because XMPP 570 uses the [UTF-8] character encoding exclusively and because PIDF 571 specifies the "application/pidf+xml" MIME type, the encapsulated MIME 572 object generated by an XMPP-CPIM gateway for presence information 573 MUST set the 'Content-type' header for that object. The 574 "Content-type" MUST be set to "application/pidf+xml" and the charset 575 MUST be set to "utf-8". 577 5.1.1 From Address 579 The 'from' attribute of an XMPP presence stanza maps to the 'From' 580 header of a "Message/CPIM" object. In XMPP, the sender's server 581 stamps or validates the "from" address and sets its value to the 582 negotiated between client and server during 583 authenticating and resource binding as defined in [XMPP-CORE]. Thus 584 an XMPP-CPIM gateway will receive from the sender's XMPP server a 585 presence stanza containing a "from" address of the form . To map the 'from' attribute of an XMPP presence stanza to 587 the 'From' header of a "Message/CPIM" object, the gateway MUST remove 588 the resource identifier, MUST append the "im:" Instant Messaging URI 589 scheme to the front of the address, and MAY include a CPIM 590 "Formal-name" for the sender (if known). 592 Example: From Address Mapping 594 XMPP 'from' attribute 595 596 ... 597 599 CPIM 'From' header 600 From: Juliet Capulet 602 In addition, the 'from' attribute of an XMPP presence stanza maps to 603 the 'entity' attribute of a PIDF root element. To map 604 the XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway 605 MUST remove the resource identifier and MUST append the "pres:" 606 Instant Messaging URI scheme to the front of the address. 608 Example: From Address Mapping (PIDF) 610 XMPP 'from' attribute 611 612 ... 613 615 PIDF 'entity' attribute 616 617 ... 618 620 Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of 621 the XMPP address contained in the XMPP 'from' attribute to the 'id' 622 attribute of the PIDF child element. 624 Example: Resource Identifier Mapping 626 XMPP 'from' attribute 627 628 ... 629 631 PIDF 'id' for 632 633 634 ... 635 636 638 5.1.2 To Address 640 The 'to' attribute of an XMPP presence stanza maps to the 'To' header 641 of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to' 642 attribute on a presence stanza, and MUST include it if the presence 643 stanza is intended for delivery directly to another user (presence 644 stanzas intended for broadcasting are stamped with a 'to' address by 645 the sender's server). Thus an XMPP-CPIM gateway will receive from 646 the sender's XMPP server a presence stanza containing a "to" address 647 of the form or . To map the 'to' 648 attribute of an XMPP presence stanza to the 'To' header of a 649 "Message/CPIM" object, the gateway MUST remove the resource 650 identifier (if included), MUST append the "im:" Instant Messaging URI 651 scheme to the front of the address, and MAY include a CPIM 652 "Formal-name" for the recipient (if known). 654 Example: To Address Mapping 656 XMPP 'to' attribute 657 658 ... 659 661 CPIM 'To' header 662 To: Romeo Montague 664 5.1.3 Stanza ID 666 An XMPP presence stanza MAY possess an 'id' attribute, which is used 667 by the sending application for the purpose of tracking stanzas and is 668 not a globally-unique identifier such as is defined by the MIME 669 Content-ID header. Because the XMPP 'id' attribute does not have the 670 same meaning as the MIME Content-ID header, it SHOULD NOT be mapped 671 to that header; however, if the 'id' is known to be unique (e.g., if 672 it is generated to be unique by the XMPP server and that fact is 673 known by the XMPP-CPIM gateway), then it SHOULD be so mapped. 675 5.1.4 Presence Type 677 An XMPP presence stanza MAY possess a 'type' attribute. If no 'type' 678 attribute is included, the presence stanza indicates that the sender 679 is available; this state maps to the PIDF basic presence type of 680 OPEN. If the 'type' attribute has a value of "unavailable", the 681 presence stanza indicates that the sender is no longer available; 682 this state maps to the PIDF basic presence type of CLOSED. Thus both 683 the absence of a 'type' attribute and a 'type' attribute set to a 684 value of "unavailable" correspond to the [CPP] "notify operation". 685 All other presence types are used to manage presence subscriptions or 686 probe for current presence; mappings for these other presence types 687 are defined under XMPP-CPIM Gateway as Presence Service (Section 6). 689 Example: Available Presence 691 XMPP available presence 692 694 PIDF basic presence (OPEN) 695 696 698 699 700 open 701 702 703 705 Example: Unavailable Presence 707 XMPP unavailable presence 708 710 PIDF basic presence (CLOSED) 711 712 714 715 716 closed 717 718 719 721 5.1.5 Show Element 723 The child element of an XMPP presence stanza provides 724 additional information about the sender's availability. The XML 725 character data of the XMPP element maps to extended 726 content in PIDF. The defined values of the element are 727 'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for 728 extended status states in the 'urn:ietf:params:xml:ns:pidf:im' 729 namespace, the XMPP values will be mapped to the PIDF values. 731 Example: Show Element 733 XMPP element 734 735 away 736 738 PIDF extended presence information 739 740 743 744 745 open 746 away 747 748 749 751 5.1.6 Status Element 753 The child element of an XMPP presence stanza provides a 754 user-defined, natural-language description of the sender's detailed 755 availability state. The XMPP element maps to the PIDF 756 child of the PIDF element. 758 Example: Status Element 760 XMPP element 761 762 away 763 retired to the chamber 764 766 PIDF element 767 768 771 772 773 open 774 away 775 776 retired to the chamber 777 778 780 5.1.7 Presence Priority 782 An XMPP presence stanza MAY contain a child element whose 783 value is an integer between -128 and +127. The value of this element 784 MAY be mapped to the 'priority' attribute of the child of 785 the PIDF element. If the value of the XMPP 786 element is negative, an XMPP-CPIM gateway MUST NOT map the value. 787 The range of allowable values for the PIDF 'priority' attribute is 788 any decimal number from zero to one inclusive, with a maximum of 789 three decimal places. If an XMPP-CPIM gateway maps these values, it 790 SHOULD treat XMPP 0 as PIDF priority='0' and 791 XMPP 127 as PIDF priority='1', mapping 792 intermediate values appropriately so that they are unique (e.g., XMPP 793 priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 794 0.015, and so on up through mapping XMPP priority 126 to PIDF 795 priority 0.992; note that this is an example only, and that the exact 796 mapping shall be determined by the XMPP-CPIM gateway). 798 Example: Presence Priority 800 XMPP element 801 802 13 803 805 PIDF element 806 807 809 810 ... 811 im:juliet@example.com 812 813 815 5.1.8 Presence Extensions 817 As defined in [XMPP-CORE], an XMPP presence stanza may contain 818 "extended" content in any namespace in order to supplement or extend 819 the semantics of the core presence stanza. With the exception of 820 extended information qualified by the 821 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E], 822 an XMPP-CPIM gateway SHOULD ignore such information and not pass it 823 through the gateway to the intended recipient. No mapping for such 824 information is defined. 826 5.1.9 Gateway-Generated CPIM and PIDF Syntax 828 5.1.9.1 CPIM Message Headers 830 CPIM specifies the existence of "Message/CPIM" headers in addition to 831 those described above, but there is no exact analogue for those 832 headers in the core XMPP specifications. These include: 834 o cc -- specifies the address of an entity that is to receive a 835 "courtesy copy" of the presence information (i.e., a non-primary 836 addressee) 837 o DateTime -- specifies the datetime at which the presence 838 information was sent 839 o NS -- specifies the namespace of a feature extension 840 o Subject -- specifies the subject or topic of the encapsulated 841 "Message/CPIM" object 842 o Require -- specifies mandatory-to-recognize features 844 An XMPP-CPIM gateway MAY independently generate such headers based on 845 its own information (e.g., the datetime at which it received a 846 presence stanza from an XMPP entity) or based on data encoded in 847 non-core XMPP extensions, but rules for doing so are out of scope for 848 this memo. 850 5.1.9.2 PIDF Elements 852 PIDF specifies the existence of XML elements in addition to those 853 described above, but there is no exact analogue for those XML 854 elements in the core XMPP specifications. These include: 856 o -- specifies an address (e.g., an im:, tel:, or mailto: 857 URI) at which one may communicate with the presentity; an 858 XMPP-CPIM gateway MAY include this element, in which case it 859 SHOULD set its value to the of the XMPP sender, 860 prepended by the "im:" Instant Messaging URI scheme. 861 o -- specifies the datetime at which the presence 862 information was sent; an XMPP-CPIM gateway MAY independently 863 generate this element based on its own information (e.g., the 864 datetime at which it received the presence stanza from an XMPP 865 entity) or based on data encoded in non-core XMPP extensions, but 866 rules for doing so are out of scope for this memo. 868 5.2 Presence Syntax Mapping from CPIM Specifications to XMPP 870 This section defines the mapping of syntax primitives from "Message/ 871 CPIM" objects with encapsulated "application/pidf+xml" objects to 872 XMPP presence stanzas. 874 Note: An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a 875 "Message/CPIM" object whose encapsulated MIME object has a 876 Content-type other than "application/pidf+xml" (with the exception of 877 multi-part MIME objects as specified in [XMPP-E2E]). 879 5.2.1 From Address 881 The 'From' header of a "Message/CPIM" object maps to the 882 portion of the 'from' attribute of an XMPP presence stanza, and the 883 'id' attribute of the PIDF child element maps to the 884 resource identifier portion XMPP 'from' attribute. Therefore, to map 885 the CPIM and PIDF information to the XMPP 'from' attribute, the 886 gateway MUST remove the "im:" Instant Messaging URI scheme from the 887 front of the address and MUST remove the CPIM "Formal-name" (if 888 provided) in order to generate the portion of the XMPP 889 'from' attribute, then add a '/' character followed by the value of 890 the PIDF element's 'id' attribute. 892 Example: From Address Mapping 894 CPIM 'From' header 895 From: Romeo Montague 897 XMPP 'from' attribute 898 899 ... 900 902 . 904 Example: Resource Identifier Mapping 906 XMPP 'from' attribute 907 908 ... 909 911 PIDF 'id' for 912 913 914 ... 915 916 918 5.2.2 To Address 920 The 'To' header of a "Message/CPIM" object maps to the 'to' attribute 921 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP 922 'to' attribute, the gateway MUST remove the "im:" Instant Messaging 923 URI scheme from the front of the address and MUST remove the CPIM 924 "Formal-name" (if provided). If the gateway possesses knowledge of 925 the resource identifier in use by the XMPP entity, the gateway MAY 926 append the resource identifier to the address. 928 Example: To Address Mapping 930 CPIM 'To' header 931 To: Juliet Capulet 933 XMPP 'to' attribute 934 935 ... 936 938 5.2.3 Courtesy Copy 940 The core XMPP specification does not include syntax for specifying a 941 "courtesy copy" (non-primary addressee) for a presence stanza. 942 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object 943 with encapsulated PIDF object that contains a 'cc' header, it SHOULD 944 NOT pass the information contained in that header on to the XMPP 945 recipient. 947 5.2.4 DateTime Header 949 The core XMPP specification does not include syntax for specifying 950 the datetime at which a presence stanza was sent. Therefore, if an 951 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated 952 PIDF object that contains a 'DateTime' header, it SHOULD NOT pass the 953 information contained in that header on to the XMPP recipient. 955 5.2.5 Subject Header 957 An XMPP presence stanza contains no information that can be mapped to 958 the 'Subject' header of a "Message/CPIM" object. Therefore, if an 959 XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated 960 PIDF object that contains a 'Subject' header, it SHOULD NOT pass the 961 information contained in that header on to the XMPP recipient. 963 5.2.6 Header Extensions 965 "Message/CPIM" objects MAY include an optional 'NS' header to specify 966 the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT 967 pass such headers through to the XMPP recipient, and no mapping for 968 such headers is defined. 970 5.2.7 Require Header 972 "Message/CPIM" objects MAY include an optional 'Require' header to 973 specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST 974 NOT pass such headers through to the XMPP recipient, and no mapping 975 for such headers is defined. 977 5.2.8 MIME Content-ID 979 XMPP does not include an element or attribute that captures a 980 globally unique ID as is defined for the Content-ID MIME header as 981 specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object 982 that includes a Content-ID, it MAY provide the Content-ID as the 983 value of the presence stanza's 'id' attribute, but this is OPTIONAL. 985 Example: Content-ID for Encapsulated Object 987 MIME header 988 Content-ID: <123456789@example.net> 990 XMPP 'id' attribute (OPTIONAL) 991 992 ... 993 995 5.2.9 Basic Presence Status 997 The basic presence status types defined in PIDF are OPEN and CLOSED. 998 The PIDF basic presence status of OPEN maps to an XMPP presence 999 stanza that possesses no 'type' attribute (indicating default 1000 availability). The PIDF basic presence status of CLOSED maps to an 1001 XMPP presence stanza that possesses a 'type' attribute with a value 1002 of "unavailable". 1004 Example: OPEN Presence 1006 PIDF basic presence (OPEN) 1007 1008 1010 1011 1012 open 1013 1014 1015 1017 XMPP available presence 1018 1020 Example: CLOSED Presence 1022 PIDF basic presence (CLOSED) 1023 1024 1026 1027 1028 closed 1029 1030 1031 1033 XMPP unavailable presence 1034 1037 5.2.10 Extended Status Information 1039 PIDF documents may contain extended content. As of this 1040 writing there are no pre-defined extended status states that can be 1041 mapped to the defined values of the XMPP element ('away', 1042 'chat', 'dnd', and 'xa'). Once PIDF extensions for such extended 1043 status states are defined within the Internet Standards Process, a 1044 gateway SHOULD map those extensions; however, any such mapping is out 1045 of scope for this memo, since the relevant PIDF extensions have not 1046 yet been defined. 1048 Example: Extended Status Information (provisional) 1050 PIDF extended presence information 1051 1052 1055 1056 1057 open 1058 busy 1059 1060 1061 1063 XMPP element 1064 1065 dnd 1066 1068 5.2.11 Note Element 1070 A PIDF element may contain a child that provides a 1071 user-defined, natural-language description of the sender's detailed 1072 availability state. The PIDF element maps to the XMPP 1073 element. 1075 Example: Note Element 1077 PIDF element 1078 1079 1082 1083 1084 open 1085 busy 1086 1087 Wooing Juliet 1088 1089 1091 XMPP element 1092 1093 dnd 1094 Wooing Juliet 1095 1097 A PIDF document with zero tuples MAY contain one or more 1098 elements as direct children of the PIDF element. There 1099 is no mapping of such a PIDF document to an XMPP presence stanza; an 1100 entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send 1101 such a PIDF document to an XMPP recipient if possible, and an 1102 XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP 1103 presence stanza (see Zero Resources (Section 6.3.2)). 1105 5.2.12 Contact Element 1107 A PIDF document may contain a element specifying the URI 1108 of an address at which the principal can be contacted (e.g., an im:, 1109 tel:, or mailto: URI). The core XMPP specification does not include 1110 syntax for specifying the URI of a contact address, since the contact 1111 address is implicit in the 'from' attribute of the XMPP presence 1112 stanza. Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" 1113 object with encapsulated PIDF object that contains a 1114 element, it SHOULD NOT pass the XML character data of the 1115 element on to the XMPP recipient. (However, see Inclusion of 1116 Complete PIDF Document (Section 5.2.15) below.) 1118 Example: PIDF Contact Element 1120 PIDF element 1121 1122 1124 1125 ... 1126 im:romeo@example.net 1127 1128 1130 XMPP presence stanza 1131 1133 5.2.13 Presence Priority 1135 The child of the PIDF element MAY possess a 1136 'priority' attribute whose value is a decimal number between zero and 1137 one (with a maximum of three decimal places). The value of this 1138 attribute MAY be mapped to the child element of an XMPP 1139 presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority 1140 values to negative values of the XMPP element. If an 1141 XMPP-CPIM gateway maps these values, it SHOULD treat PIDF 1142 priority='0' as XMPP 0 and PIDF priority='1' as 1143 127, mapping intermediate values appropriately 1144 so that they are unique (e.g., PIDF priorities between 0.001 and 1145 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to 1146 XMPP priority 2, and so on up through mapping PIDF priorities between 1147 0.992 and 0.999 to XMPP priority 126; note that this is an example 1148 only, and that the exact mapping shall be determined by the XMPP-CPIM 1149 gateway). 1151 5.2.14 Timestamp Element 1153 The core XMPP specification does not include syntax for specifying 1154 the datetime or timestamp at which a presence stanza was sent. 1155 Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object 1156 with encapsulated PIDF object that contains a element, 1157 it SHOULD NOT pass the XML character data of the element 1158 on to the XMPP recipient. 1160 5.2.15 Inclusion of Complete PIDF Document 1162 Certain PIDF elements do not map to XMPP presence stanza syntax 1163 (e.g., the XML character data of the element). However, 1164 an XMPP client may be able to handle such information by parsing a 1165 native PIDF document. To make this possible, an XMPP-CPIM gateway 1166 MAY include the complete PIDF document as a child element of the 1167 presence stanza, as described in [XMPP-PIDF]. If an XMPP client does 1168 not understand this extended data, it naturally MUST ignore it. 1170 6. XMPP-CPIM Gateway as Presence Service 1172 [CPP] defines semantics for an abstract presence service. An 1173 XMPP-CPIM gateway MAY function as such a presence service, and if so 1174 an XMPP entity can use defined XMPP syntax to interact with the 1175 gateway's presence service. Because [PIDF] does not specify syntax 1176 for semantic operations such as subscribe, this section defines only 1177 the XMPP interactions with the presence service offered by an 1178 XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF. 1179 (Note: Detailed information about XMPP presence services can be found 1180 in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD 1181 implement the syntax, semantics, and server business rules defined 1182 therein.) 1184 6.1 Requesting a Subscription 1186 If an XMPP entity wants to subscribe to the presence information of a 1187 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a 1188 presence stanza of type "subscribe" to the target presentity. The 1189 syntax mapping is as follows: 1191 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP 1192 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway 1193 MUST append the "pres:" Presence URI scheme to the front of the 1194 address. 1195 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP 1196 "target parameter" field (pres:user@host). The XMPP-CPIM gateway 1197 MUST append the "pres:" Presence URI scheme to the front of the 1198 address. 1199 o There is no XMPP mapping for the CPP "duration parameter", since 1200 XMPP subscriptions are active until they have been explicitly 1201 "unsubscribed". 1202 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" 1203 field. 1205 If the target presentity approves the subscription request (through 1206 whatever protocol it uses to interact with the gateway), the 1207 XMPP-CPIM gateway MUST return a presence stanza of type "subscribed" 1208 to the XMPP entity and notify the XMPP entity of the target's current 1209 available presence. Thereafter, until the subscription is cancelled, 1210 the gateway MUST notify the subscribing XMPP entity every time the 1211 target's presence information changes. 1213 If the target presentity denies the subscription request, the 1214 XMPP-CPIM gateway MUST return a presence stanza of type 1215 "unsubscribed" to the XMPP entity and MUST NOT invoke the notify 1216 operation. 1218 In addition to the approval and denial cases, one of the following 1219 exceptions may occur: 1221 o The target parameter (XMPP "to" address) does not refer to a valid 1222 presentity; if this exception occurs, the XMPP-CPIM gateway MUST 1223 return an stanza error to the XMPP entity. 1224 o Access control rules do not permit the entity to subscribe to the 1225 target; if this exception occurs, the XMPP-CPIM gateway MUST 1226 return a stanza error to the XMPP entity. 1227 o There exists a pre-existing subscription or in-progress subscribe 1228 operation between the XMPP entity and the target presentity; if 1229 this exception occurs, the XMPP-CPIM gateway SHOULD return a 1230 stanza error to the XMPP entity. 1232 XMPP services assume that a subscription is active until it is 1233 explicitly terminated. However, non-XMPP services may implement 1234 subscriptions of limited duration, which must be periodically 1235 refreshed in order to mimic the permanence of XMPP subscriptions. 1236 Therefore, an XMPP-to-CPIM gateway may need to send such refreshes to 1237 the non-XMPP entity on behalf of the XMPP entity to that the 1238 subscription does not expire. Whether such refreshes are necessary 1239 depends on the native protocol implemented by the CPIM-aware non-XMPP 1240 service to which the gateway is translating. 1242 6.2 Receiving a Subscription Request 1244 If a non-XMPP presentity wants to subscribe to the presence 1245 information of an XMPP entity through an XMPP-CPIM gateway, it MUST 1246 use whatever protocol it uses to interact with the gateway in order 1247 to request the subscription; subject to local access rules, the 1248 gateway MUST then send a presence stanza of type "subscribe" to the 1249 XMPP entity from the non-XMPP watcher. The syntax mapping is as 1250 follows: 1252 o The CPP "watcher parameter" field (pres:user@host) MUST be mapped 1253 to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway 1254 MUST remove the "pres:" Presence URI scheme from the front of the 1255 address. 1256 o The CPP "target parameter" field (pres:user@host) MUST be mapped 1257 to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway 1258 MUST remove the "pres:" Presence URI scheme from the front of the 1259 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". 1263 o The CPP "TransID" field SHOULD be mapped to the XMPP 'id' 1264 attribute. 1266 If the target XMPP entity approves the subscription request, it MUST 1267 send a presence stanza of type "subscribed" to the watcher 1268 presentity. The XMPP-CPIM gateway MUST then notify the watcher 1269 presentity of the target XMPP entity's current available presence. 1270 Thereafter, until the subscription is cancelled, the gateway MUST 1271 notify the watcher presentity every time the target's presence 1272 information changes. 1274 If the target XMPP entity denies the subscription request, it MUST 1275 send a presence stanza of type "unsubscribed" to the watcher 1276 presentity. The XMPP-CPIM gateway MUST NOT invoke the notify 1277 operation. 1279 In addition to the approval and denial cases, one of the following 1280 exceptions MAY occur: 1282 o The target parameter (XMPP "to" address) does not refer to a valid 1283 XMPP entity 1284 o Access control rules do not permit the watcher presentity to 1285 subscribe to the target XMPP entity 1286 o There exists a pre-existing subscription or in-progress subscribe 1287 operation between the watcher presentity and the target XMPP 1288 entity 1290 If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform 1291 the watcher presentity of failure. 1293 XMPP services assume that a subscription is active until it is 1294 explicitly terminated. With the exception of handling duration 1295 parameters whose value is zero, handling duration parameters will be 1296 highly dependent on the implementation and requirements of the 1297 XMPP-CPIM gateway. Since there are no explicit requirements for 1298 supporting a "duration parameter" specified in either [IMP-MODEL] or 1299 [IMP-REQS], duration parameter mapping is a local issue that falls 1300 outside the scope of this memo. However, an XMPP-CPIM gateway MAY 1301 keep track of the duration parameter if received from an entity on 1302 the non-XMPP service and delete the subscription after that duration 1303 parameter expires. 1305 6.3 The Notify Operation 1307 An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the 1308 presence information associated with an XMPP entity or CPP presentity 1309 changes and there are subscribers to that information on the other 1310 side of the gateway. The syntax mapping for presence information 1311 related to a notify operation is defined under Mapping for Presence 1312 (Section 5). 1314 6.3.1 Multiple Resources 1316 Semantically, PIDF contains the notion of multiple presence "tuples". 1317 Normally, a PIDF document will contain at least one tuple but MAY 1318 contain more than one tuple (or zero tuples, for which see next 1319 section). In the terminology of XMPP, each tuple would map to 1320 presence information for a separate resource. However, XMPP does not 1321 include the ability to send presence information about more than one 1322 resource at a time, since the resource that generates the presence 1323 information is contained in the 'from' address of a presence stanza. 1324 Therefore, an XMPP-CPIM gateway that acts as a presence service 1325 SHOULD split a PIDF document that contains multiple tuples into 1326 multiple XMPP presence stanzas, and SHOULD generate only one PIDF 1327 document (with multiple tuples) if an XMPP user currently has 1328 multiple connected resources. 1330 In the interest of not multiplying XMPP stanzas beyond necessity, an 1331 XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the 1332 presence information contained in a PIDF tuple communicates a change 1333 in the availability status of the device or application associated 1334 with that tuple ID. 1336 In the interest of complying with the PIDF recommendation to provide 1337 information about multiple "resources" in multiple tuples rather than 1338 in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include 1339 information about all of an XMPP user's resources in one PIDF 1340 document (with one tuple for each resource), even if the availability 1341 status of only one resource has changed. 1343 6.3.2 Zero Resources 1345 A PIDF document may contain zero tuples. For example: 1347 PIDF Document with Zero Tuples 1349 1352 Because (1) the 'entity' attribute of a PIDF element maps 1353 to the portion of an XMPP address and (2) the 'id' 1354 attribute of a PIDF element maps to the resource identifier 1355 portion of an XMPP address, a PIDF document that contains zero tuples 1356 would provide presence information about a rather than a 1357 when mapped to XMPP. Although the notion of 1358 presence notifications about a mere user rather than one of the 1359 user's resources is nearly meaningless in the XMPP context, an 1360 XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an 1361 XMPP presence stanza whose 'from' address is the user@host of the 1362 non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a 1363 PIDF document with zero children when receiving a presence 1364 stanza from an XMPP entity (i.e., all PIDF documents communicated by 1365 the gateway to a non-XMPP service MUST contain at least one 1366 element). 1368 6.4 Unsubscribing 1370 If an XMPP entity wants to unsubscribe from the presence of a 1371 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a 1372 presence stanza of type "unsubscribe" to the target presentity. The 1373 syntax mapping is as follows: 1375 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP 1376 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway 1377 MUST append the "pres:" Presence URI scheme to the front of the 1378 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. 1383 o The CPP "duration parameter" MUST be set to zero. 1384 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" 1385 field. 1387 If the target parameter (XMPP "to" address) does not refer to a valid 1388 presentity, the XMPP-CPIM gateway MUST return an 1389 stanza error to the XMPP entity. 1391 Upon receiving the presence stanza of type "unsubscribe" from the 1392 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence 1393 notifications to the XMPP entity. 1395 6.5 Cancelling a Subscription 1397 If an XMPP entity wants to cancel a non-XMPP presentity's 1398 subscription to the entity's presence through an XMPP-CPIM gateway, 1399 it MUST send a presence stanza of type "unsubscribed" to the target 1400 presentity. The syntax mapping is as follows: 1402 o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP 1403 "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway 1404 MUST add the "pres:" Presence URI scheme to the front of the 1405 address. 1406 o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP 1407 "target parameter" field (pres:user@host). The XMPP-CPIM gateway 1408 MUST add the "pres:" Presence URI scheme to the front of the 1409 address. 1410 o The CPP "duration parameter" MUST be set to zero. 1411 o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" 1412 field. 1414 Upon receiving the presence stanza of type "unsubscribed" from the 1415 XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence 1416 notifications to the watcher presentity. 1418 7. Security Considerations 1420 Detailed security considerations for instant messaging and presence 1421 protocols are given in [IMP-REQS], specifically in Sections 5.1 1422 through 5.4. 1424 This document specifies methods for exchanging instant messages and 1425 presence information through a gateway that implements [CPIM] and 1426 [CPP]. Such a gateway MUST be compliant with the minimum security 1427 requirements of the instant messaging and presence protocols with 1428 which it interfaces. The introduction of gateways to the security 1429 model of instant messaging and presence in RFC 2779 also introduces 1430 some new risks. In particular, end-to-end security properties 1431 (especially confidentiality and integrity) between instant messaging 1432 and presence user agents that interface through an XMPP-CPIM gateway 1433 can be provided only if common formats are supported; these formats 1434 are specified fully in [XMPP-E2E]. 1436 Normative References 1438 [CPIM] Peterson, J., "Common Profile for Instant Messaging 1439 (CPIM)", draft-ietf-impp-im-04 (work in progress), August 1440 2003. 1442 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 1443 draft-ietf-impp-pres-04 (work in progress), August 2003. 1445 [IMP-MODEL] 1446 Day, M., Rosenberg, J. and H. Sugano, "A Model for 1447 Presence and Instant Messaging", RFC 2778, February 2000, 1448 . 1450 [IMP-REQS] 1451 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 1452 Presence Protocol Requirements", RFC 2779, February 2000. 1454 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1455 Extensions (MIME) Part One: Format of Internet Message 1456 Bodies", RFC 2045, November 1996. 1458 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant 1459 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 1460 (work in progress), January 2003. 1462 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. 1463 and J. Peterson, "CPIM Presence Information Data Format", 1464 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 1466 [STRINGPREP] 1467 Hoffman, P. and M. Blanchet, "Preparation of 1468 Internationalized Strings ("STRINGPREP")", RFC 3454, 1469 December 2002. 1471 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1472 Requirement Levels", BCP 14, RFC 2119, March 1997. 1474 [URL-GUIDE] 1475 Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, 1476 "Guidelines for new URL Schemes", RFC 2718, November 1999. 1478 [US-ASCII] 1479 Cerf, V., "ASCII format for network interchange", RFC 20, 1480 October 1969. 1482 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1483 10646", STD 63, RFC 3629, November 2003. 1485 [XMPP-CORE] 1486 Saint-Andre (ed.), P., "Extensible Messaging and Presence 1487 Protocol (XMPP): Core", draft-ietf-xmpp-core-23 (work in 1488 progress), April 2004. 1490 [XMPP-E2E] 1491 Saint-Andre (ed.), P., "End-to-End Object Encryption in 1492 the Extensible Messaging and Presence Protocol (XMPP)", 1493 draft-ietf-xmpp-e2e-07 (work in progress), December 2003. 1495 [XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence 1496 Protocol (XMPP): Instant Messaging and Presence", 1497 draft-ietf-xmpp-im-22 (work in progress), April 2004. 1499 Informative References 1501 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1502 2001. 1504 [MIMETYPES] 1505 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1506 Extensions (MIME) Part Two: Media Types", RFC 2046, 1507 November 1996. 1509 [XMPP-PIDF] 1510 Saint-Andre, P., "Transporting Presence Information Data 1511 Format (PIDF) over the Extensible Messaging and Presence 1512 Protocol (XMPP)", draft-saintandre-xmpp-pidf-00 (work in 1513 progress), February 2004. 1515 Author's Address 1517 Peter Saint-Andre 1518 Jabber Software Foundation 1520 EMail: stpeter@jabber.org 1522 Appendix A. Revision History 1524 Note to RFC Editor: please remove this entire appendix, and the 1525 corresponding entries in the table of contents, prior to publication. 1527 A.1 Changes from draft-ietf-xmpp-cpim-04 1529 o Addressed feedback from IESG. 1530 o Removed Discussion Venue section. 1531 o Corrected @2f to #2f in Section 3.3. 1532 o In Sections 4.2.3, 4.2.4, 5.2.3, 5.2.4, 5.2.5, and 5.2.14, 1533 clarified that it is only the information contained in the 1534 offending header or XML element that should not be passed from 1535 CPIM to XMPP if there is no mapping, not the entire "Message/CPIM" 1536 object. 1537 o Specified that a gateway should return a warning or error to a 1538 non-XMPP sending application if it receives a "Message/CPIM" 1539 object with a 'Require:' header detailing mandatory-to-recognize 1540 features. 1541 o Changed SHOULD to MUST regarding mapping of US-ASCII and UTF-8 1542 "Message/CPIM" objects in Section 4.2.9. 1543 o In Section 5.1.5, larified that work on PIDF extended status 1544 states (e.g., "away" and "dnd") is ongoing (not qualified by the 1545 'urn:ietf:params:xml:ns:pidf:im' namespace) and that gateways 1546 should support those extensions once they are defined. 1547 o Specified mapping of tuple IDs to resource identifiers in Section 1548 5.2.1. 1549 o Added text to Section 6.1 regarding the possibility that a gateway 1550 may need to refresh subscription states with the non-XMPP service, 1551 depending on what protocol that service implements. 1552 o Changed RFC 2279 reference to RFC 3629. 1554 A.2 Changes from draft-ietf-xmpp-cpim-03 1556 o Addressed feedback from WG Chairs. 1558 A.3 Changes from draft-ietf-xmpp-cpim-02 1560 o Removed references to UTF-16. 1561 o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data. 1562 o Added information about internationalization of addresses. 1563 o Completed formatting changes to meet RFC Editor requirements. 1565 A.4 Changes from draft-ietf-xmpp-cpim-01 1567 o Added subsection about handling presence notifications for 1568 multiple XMPP resources and multiple PIDF tuples. 1569 o Added subsection about PIDF documents that contain zero tuples. 1570 o Further specified mapping between XMPP addresses and CPIM instant 1571 inboxes and presentities. 1573 A.5 Changes from draft-ietf-xmpp-cpim-00 1575 o Updated references. 1576 o Made several small editorial changes. 1578 Intellectual Property Statement 1580 The IETF takes no position regarding the validity or scope of any 1581 intellectual property or other rights that might be claimed to 1582 pertain to the implementation or use of the technology described in 1583 this document or the extent to which any license under such rights 1584 might or might not be available; neither does it represent that it 1585 has made any effort to identify any such rights. Information on the 1586 IETF's procedures with respect to rights in standards-track and 1587 standards-related documentation can be found in BCP-11. Copies of 1588 claims of rights made available for publication and any assurances of 1589 licenses to be made available, or the result of an attempt made to 1590 obtain a general license or permission for the use of such 1591 proprietary rights by implementors or users of this specification can 1592 be obtained from the IETF Secretariat. 1594 The IETF invites any interested party to bring to its attention any 1595 copyrights, patents or patent applications, or other proprietary 1596 rights which may cover technology that may be required to practice 1597 this standard. Please address the information to the IETF Executive 1598 Director. 1600 Full Copyright Statement 1602 Copyright (C) The Internet Society (2004). All Rights Reserved. 1604 This document and translations of it may be copied and furnished to 1605 others, and derivative works that comment on or otherwise explain it 1606 or assist in its implementation may be prepared, copied, published 1607 and distributed, in whole or in part, without restriction of any 1608 kind, provided that the above copyright notice and this paragraph are 1609 included on all such copies and derivative works. However, this 1610 document itself may not be modified in any way, such as by removing 1611 the copyright notice or references to the Internet Society or other 1612 Internet organizations, except as needed for the purpose of 1613 developing Internet standards in which case the procedures for 1614 copyrights defined in the Internet Standards process must be 1615 followed, or as required to translate it into languages other than 1616 English. 1618 The limited permissions granted above are perpetual and will not be 1619 revoked by the Internet Society or its successors or assignees. 1621 This document and the information contained herein is provided on an 1622 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1623 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1624 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1625 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1626 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1628 Acknowledgment 1630 Funding for the RFC Editor function is currently provided by the 1631 Internet Society.