XMPP CPIM Mapping Reference: draft-miller-xmpp-cpim-00 From: http://www.ietf.org/internet-drafts/draft-miller-xmpp-cpim-00.txt ----------------------------------------------------------------------- Network Working Group J. Miller Internet-Draft P. Saint-Andre Expires: December 20, 2002 Jabber Software Foundation T. Bamonti Jabber, Inc. June 21, 2002 XMPP CPIM Mapping draft-miller-xmpp-cpim-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 20, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a mapping of the eXtensible Messaging and Presence Protocol (XMPP) to the Common Presence and Instant Messaging specification. Miller, et al. Expires December 20, 2002 [Page 1] Internet-Draft XMPP CPIM Mapping June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Conventions Used in this Document . . . . . . . . . . . . 3 1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 3 1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 3 2. CPIM Gateway . . . . . . . . . . . . . . . . . . . . . . . 4 3. CPIM Mapping for Instant Messages . . . . . . . . . . . . 5 3.1 Identification of INSTANT INBOXes . . . . . . . . . . . . 5 3.2 The Message Operation . . . . . . . . . . . . . . . . . . 5 3.2.1 Message Parameters . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3 Message Delivery . . . . . . . . . . . . . . . . . . . . . 6 4. CPIM Mapping for Presence . . . . . . . . . . . . . . . . 8 4.1 Identification of PRESENTITIES . . . . . . . . . . . . . . 8 4.2 The Presence Service . . . . . . . . . . . . . . . . . . . 8 4.2.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 8 4.2.1.1 Duration Parameter Considerations . . . . . . . . . . . . 9 4.2.1.2 Subscription Exceptions . . . . . . . . . . . . . . . . . 9 4.2.1.3 Completing the Subscribe Operation . . . . . . . . . . . . 10 4.2.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 10 4.2.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 11 4.2.4 The Fetch Operation . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . 17 Miller, et al. Expires December 20, 2002 [Page 2] Internet-Draft XMPP CPIM Mapping June 2002 1. Introduction 1.1 Overview Common Presence and Instant Messaging (CPIM) [1] describes an abstract framework for interoperability of instant messaging and presence systems compliant with RFC 2779 [2]. This document describes how systems based on the eXtensible Messaging and Presence Protocol (XMPP) map to the abstract CPIM model. 1.2 Terminology This memo makes use of the vocabulary defined in RFC 2778 [3]. Terms such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as defined therein. This memo also makes use of the vocabulary defined in XMPP Core [4]. Terms such as ENTITY, JABBER IDENTIFIER (JID), NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE IDENTIFIER, MESSAGE ELEMENT, PRESENCE ELEMENT, and IQ ELEMENT are used in the same meaning as defined therein. 1.3 Conventions Used in this Document The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 1.4 Discussion Venue The authors welcome discussion and comments related to the topics presented in this document, preferably on the "jabber- ietf@jabber.org" mailing list (archives and subscription information are available at http://www.jabber.org/cgi-bin/mailman/listinfo/ jabber-ietf/). 1.5 Intellectual Property Notice This document is in full compliance with all provisions of Section 10 of RFC 2026. Parts of this specification use the term "jabber" for identifying URI schemes, namespaces, and other protocol syntax. Jabber[tm] is a trademark of Jabber, Inc. If the IETF places this document, or a successor document, on the standards track, then Jabber, Inc. grants permission for use of the trademark "Jabber" in association with that specification. Miller, et al. Expires December 20, 2002 [Page 3] Internet-Draft XMPP CPIM Mapping June 2002 2. CPIM Gateway A common method for achieving interoperability between two disparate systems or services is through the use of a "gateway" that interprets the protocols of each system and translates them into the protocols of the other. CPIM defines the common method of agreement to be used for interoperability of instant messaging and presence systems/ services compliant with RFC 2779 [2]. This document describes the manner in which an instant messaging and presence system based on XMPP will interface to a gateway that supports the CPIM specifications. As such, this document assumes no more about the target instant messaging and presence system than that it also complies with the abstract CPIM service definition. +-------------+ +-------------+ +--------------+ | | | | | | | XMPP | | CPIM | | CPIM- | | Service | <----> | Gateway | <----> | Compliant | | | | | | Service | +-------------+ +-------------+ +--------------+ Miller, et al. Expires December 20, 2002 [Page 4] Internet-Draft XMPP CPIM Mapping June 2002 3. CPIM Mapping for Instant Messages This section describes how a CPIM compliant gateway MAY map instant messages between an XMPP service and a CPIM service. 3.1 Identification of INSTANT INBOXes There is a one-to-one relationship between an XMPP ENTITY and a CPIM INSTANT INBOX. This relationship is made possible using a JABBER IDENTIFER (JID) and conforming to RFC 2822 [7] (e.g., "node@domain") where the "node" part maps to an XMPP NODE IDENTIFIER and is interpreted and assigned semantics only by the DOMAIN IDENTIFIER specified in the "domain" part. 3.2 The Message Operation 3.2.1 Message Parameters When an XMPP service sends or receives an INSTANT MESSAGE it uses the XMPP MESSAGE ELEMENT. The XMPP MESSAGE ELEMENT maps to the CPIM service as follows: When sending messages from XMPP to CPIM: o The XMPP "from" attribute (node@domain) maps to the CPIM "message source" field (im:node@domain). The CPIM gateway SHOULD append the "im:" Instant Messaging URI scheme to the front of the address. o The XMPP "to" attribute (node@domain) maps to the CPIM "destination" field (im:node@domain). The CPIM gateway SHOULD append the "im:" Instant Messaging URI scheme to the front of the address. o The XMPP "id" attribute maps to the CPIM "TransID" field. o The XMPP element maps to the CPIM "message" field. When sending messages from CPIM to XMPP: o The CPIM "message source" field (im:node@domain) maps to the XMPP "from" attribute (node@domain). The CPIM gateway SHOULD remove the "im:" Instant Messaging URI scheme from the front of the address. o The CPIM "destination" field (im:node@domain) maps to the XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove the "im:" Instant Messaging URI scheme to the front of the address. Miller, et al. Expires December 20, 2002 [Page 5] Internet-Draft XMPP CPIM Mapping June 2002 o The CPIM "TransID" field maps to the XMPP "id" attribute. o The CPIM "message" field maps to the XMPP element. 3.2.2 Exceptions During a message operation, an exception is encountered if: o The source or destination does not refer to a valid INSTANT INBOX; or o Access control does not permit the application to request this operation; or o The service is unable to successfully deliver the message. Exceptions between an XMPP service and a CPIM service are mapped as follows: o Messaging errors originating from XMPP to CPIM SHOULD translate to a CPIM "response status" of failure. o Messaging errors originating from CPIM to XMPP SHOULD translate to an XMPP element of type code = 503 (Service Unavailable). Since the CPIM service does not specify error codes to distinguish between different error events, it is not possible to map context- specific error information originating from the CPIM service back to the XMPP service. However, it is expected that most real-world instant messaging and presence service implementations will support some level of contextual exception handling. In these cases, the CPIM gateway would be designed in a fashion to map the contextual error messages between interoperating systems. For the purpose of this document, since all CPIM exceptions result in a generic status of "failure", the associated mapping to the XMPP service SHOULD be to the XMPP element of type code = 503 (Service Unavailable). 3.2.3 Message Delivery By default, XMPP services operate on an "exception" basis. That is, if an operation is successful, no status response is sent. If an operation is unsuccessful, then an response is delivered. This is by design to limit unnecessary network overhead. When sending a message from CPIM to XMPP: o If the XMPP service is able to successfully deliver the message, Miller, et al. Expires December 20, 2002 [Page 6] Internet-Draft XMPP CPIM Mapping June 2002 no status response will be delivered. If no response is received by the CPIM gateway (i.e., no error message is delivered) after delivering a message to an XMPP service, then a CPIM gateway response operation having status "success" SHOULD be sent to the CPIM service. o If the XMPP service is unable to successfully deliver the message, an XMPP message will be sent to the CPIM gateway. This will result in a response operation having status "failure" sent to the CPIM service. The XMPP "id" attribute returned with the error message will be identical to the "transID" value of the originating CPIM message. The CPIM gateway will map the XMPP "id" to the CPIM "transID" parameter for delivery of the error message to the CPIM service. When sending a message from XMPP to CPIM: o If the CPIM service is able to successfully deliver the message, the "success" response SHOULD be silently dropped. o If the CPIM service is unable to successfully deliver the message, a response status message of type "failure" will be generated by the CPIM service. This SHOULD result in the CPIM gateway sending an XMPP message of type code = 503 (Service Unavailable) to the XMPP service. Miller, et al. Expires December 20, 2002 [Page 7] Internet-Draft XMPP CPIM Mapping June 2002 4. CPIM Mapping for Presence This section describes how a CPIM compliant gateway SHOULD map presence information between an XMPP service and a CPIM service. 4.1 Identification of PRESENTITIES There is a one-to-one relationship between an XMPP ENTITY and a CPIM PRESENTITY using a JABBER IDENTIFER (JID) and conforming to RFC 2822 [7] (e.g., "node@domain") where the "node" part maps to an XMPP NODE IDENTIFIER and is interpreted and assigned semantics only by the DOMAIN IDENTIFIER specified in the "domain" part (e.g., "node@domain"). 4.2 The Presence Service 4.2.1 The Subscribe Operation This section describes how a "subscribe" operation will be performed between an XMPP service and a CPIM service. When an application wants to (periodically) receive the presence information associated with a PRESENTITY, it invokes the subscribe operation. When an XMPP service performs a "subscribe" operation it uses the XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service as follows: When sending a subscription request from XMPP to CPIM: o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "to" attribute (node@domain) maps to the CPIM "target parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o There is no XMPP mapping for the CPIM "duration parameter". XMPP subscriptions are active until they have been explicitly "unsubscribed". See Duration Parameter Considerations (Section 4.2.1.1) below for further discussion regarding the "duration parameter". o The XMPP "id" attribute maps to the CPIM "TransID" field. Miller, et al. Expires December 20, 2002 [Page 8] Internet-Draft XMPP CPIM Mapping June 2002 o The XMPP "subscribe" attribute maps to the CPIM "subscribe" operation field. When sending a subscription request from CPIM to XMPP: o The CPIM "watcher parameter" field (pres:node@domain) maps to the XMPP "from" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "target parameter" field (im:node@domain) maps to the XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme to the front of the address. o The CPIM "TransID" field maps to the XMPP "id" attribute. o The CPIM "subscribe" operation field maps to the XMPP "subscribe" attribute. 4.2.1.1 Duration Parameter Considerations The XMPP service assumes a subscription to be active until it is explicitly unsubscribed. Handling/mapping of a subscription "duration parameter" will be highly dependent on the implementation and requirements of the associated instant messaging and presence system represented in this document by the CPIM service. Since there are no explicit requirements for supporting a "duration parameter" specified in either RFC 2778 [3] or RFC 2779 [2], this would be an implementation/service specific consideration that falls outside of the scope of this document. 4.2.1.2 Subscription Exceptions During a "subscribe" operation, one of the following exceptions MAY be encountered: o The watcher or target parameter ("from" or "to") does not refer to a valid PRESENTITY (or Jabber Identifier). o Access control MAY NOT permit the application to request this operation. o There MAY be a pre-existing subscription or in-progress subscribe operation between the watcher and the target entities. o The target PRESENTITY denies the subscription request. Miller, et al. Expires December 20, 2002 [Page 9] Internet-Draft XMPP CPIM Mapping June 2002 Exceptions between an XMPP service and a CPIM service are mapped as follows: o Messaging errors originating from XMPP to CPIM SHOULD translate to a CPIM "response status" of failure. o Messaging errors originating from CPIM to XMPP SHOULD translate to an XMPP element of type code = 503 (Service Unavailable). 4.2.1.3 Completing the Subscribe Operation If the subscribe request from the XMPP service to the CPIM service is successful: o The CPIM issues a "response status" = "success". This is mapped to the XMPP PRESENCE ELEMENT attribute "type" = "subscribed" and returned to the subscribing XMPP ENTITY. o A notify operation, corresponding to the CPIM "target's" presence information, is immediately invoked for the subscribing XMPP ENTITY (see The Notify Operation (Section 4.2.2) below). o Until the subscription is "unsubscribed", a notify operation is invoked for the subscribing XMPP ENTITY every time the CPIM "target's" presence information changes. If the subscribe request from the CPIM service to the XMPP service is successful: o The XMPP service issues a PRESENCE ELEMENT response attribute "type" = "subscribed". This is mapped to the CPIM "response status" = "success" and returned to the subscribing CPIM "watcher". o A notify operation, corresponding to the XMPP ENTITY's presence information, is immediately invoked for the subscribing CPIM watcher (see The Notify Operation (Section 4.2.2) below). o Until the subscription is "unsubscribed", a notify operation is invoked for the subscribing CPIM watcher every time the XMPP ENTITY's presence information changes. 4.2.2 The Notify Operation This section describes how a "Notify" operation will be performed between an XMPP service and a CPIM service. Miller, et al. Expires December 20, 2002 [Page 10] Internet-Draft XMPP CPIM Mapping June 2002 A notify operation is invoked whenever the presence information associated with an XMPP ENTITY or a CPIM PRESENTITY changes and there are subscribers to that information. When an XMPP service performs a "notify" operation indicating a change in presence, it uses the XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service as follows: When sending a presence notification from XMPP to CPIM: o The XMPP "from" attribute (node@domain) maps to the CPIM "target parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "to" attribute (node@domain) maps to the CPIM "watcher parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "id" attribute maps to the CPIM "TransID" field. o The XMPP "type" attribute maps to the CPIM "presence information" field. When sending a presence notification from CPIM to XMPP: o The CPIM "target parameter" field (pres:node@domain) maps to the XMPP "from" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "watcher parameter" field (im:node@domain) maps to the XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "TransID" field maps to the XMPP "id" attribute. o The CPIM "presence information" operation field maps to the XMPP "type" attribute. 4.2.3 The Unsubscribe Operation This section describes how an "unsubscribe" operation will be performed between an XMPP service and a CPIM service. When an application wants to cancel a subscription associated with a Miller, et al. Expires December 20, 2002 [Page 11] Internet-Draft XMPP CPIM Mapping June 2002 PRESENTITY, it invokes the unsubscribe operation. When an XMPP service performs an "unsubscribe" operation it uses the XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service as follows: When sending an unsubscribe command from XMPP to CPIM: o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "to" attribute (node@domain) maps to the CPIM "target parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "id" attribute maps to the CPIM "TransID" field. o The XMPP "unsubscribe" attribute maps to the CPIM "unsubscribe" field. When sending an unsubscribe command from CPIM to XMPP: o The CPIM "watcher parameter" field (pres:node@domain) maps to the XMPP "from" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "target parameter" field (im:node@domain) maps to the XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "TransID" field maps to the XMPP "id" attribute. o The CPIM "unsubscribe" operation field maps to the XMPP "unsubscribe" attribute. 4.2.4 The Fetch Operation This section describes how a "fetch" operation will be performed between an XMPP service and a CPIM service. The "fetch" operation is invoked when an application wants to directly request presence information to be supplied immediately. Miller, et al. Expires December 20, 2002 [Page 12] Internet-Draft XMPP CPIM Mapping June 2002 When an XMPP service performs a "fetch" operation it uses the XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service as follows: When sending a fetch request from XMPP to CPIM: o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "to" attribute (node@domain) maps to the CPIM "target parameter" field (pres:node@domain). The CPIM gateway SHOULD append the "pres:" Presence URI scheme to the front of the address. o The XMPP "id" attribute maps to the CPIM "TransID" field. o The XMPP "probe" attribute maps to the CPIM "subscribe 0" operation. When sending a fetch request from CPIM to XMPP: o The CPIM "watcher parameter" field (pres:node@domain) maps to the XMPP "from" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "target parameter" field (im:node@domain) maps to the XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove the "pres:" Presence URI scheme from the front of the address. o The CPIM "TransID" field maps to the XMPP "id" attribute. o The CPIM "subscribe 0" operation field maps to the XMPP "probe" attribute. Miller, et al. Expires December 20, 2002 [Page 13] Internet-Draft XMPP CPIM Mapping June 2002 5. Security Considerations XMPP places a high priority on security and provides mechanisms for securing client-to-server and server-to-server communications, including payload encryption, digital signatures, client-server authentication, and server-server authentication. Details regarding XMPP security are provided in XMPP Core [4] and XMPP IM [6]. Details regarding CPIM security considerations can be found in Common Presence and Instant Messaging (CPIM) [1]. Miller, et al. Expires December 20, 2002 [Page 14] Internet-Draft XMPP CPIM Mapping June 2002 References [1] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rosenberg, J., Sparks, R. and H. Sugano, "A Common Profile for Instant Messaging (CPIM)", November 2001. [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000, . [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000, . [4] Miller, J. and P. Saint-Andre, "XMPP Core (draft-miller-jabber- xmpp-core-00, work in progress)", June 2002. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft- miller-jabber-xmpp-im-00, work in progress)", June 2002. [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Authors' Addresses Jeremie Miller Jabber Software Foundation 1899 Wynkoop Street, Suite 600 Denver, CO 80202 US EMail: jeremie@jabber.org URI: http://www.jabber.org/ Peter Saint-Andre Jabber Software Foundation 1899 Wynkoop Street, Suite 600 Denver, CO 80202 US EMail: stpeter@jabber.org URI: http://www.jabber.org/ Miller, et al. Expires December 20, 2002 [Page 15] Internet-Draft XMPP CPIM Mapping June 2002 T. Bamonti Jabber, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 US EMail: tbamonti@jabber.com URI: http://www.jabber.com/ Miller, et al. Expires December 20, 2002 [Page 16] Internet-Draft XMPP CPIM Mapping June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Miller, et al. Expires December 20, 2002 [Page 17]