| TOC |
|
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 (C) The Internet Society (2002). All Rights Reserved.
This document describes a mapping of the eXtensible Messaging and Presence Protocol (XMPP) to the Common Presence and Instant Messaging specification.
| TOC |
| TOC |
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.
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.
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].
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/).
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.
| TOC |
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 |
+-------------+ +-------------+ +--------------+
| TOC |
This section describes how a CPIM compliant gateway MAY map instant messages between an XMPP service and a CPIM service.
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.
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:
When sending messages from CPIM to XMPP:
During a message operation, an exception is encountered if:
Exceptions between an XMPP service and a CPIM service are mapped as follows:
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 <error/> element of type code = 503 (Service Unavailable).
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 <error/> response is delivered. This is by design to limit unnecessary network overhead.
When sending a message from CPIM to XMPP:
When sending a message from XMPP to CPIM:
| TOC |
This section describes how a CPIM compliant gateway SHOULD map presence information between an XMPP service and a CPIM service.
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").
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:
When sending a subscription request from CPIM to XMPP:
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.
During a "subscribe" operation, one of the following exceptions MAY be encountered:
Exceptions between an XMPP service and a CPIM service are mapped as follows:
If the subscribe request from the XMPP service to the CPIM service is successful:
If the subscribe request from the CPIM service to the XMPP service is successful:
This section describes how a "Notify" operation will be performed between an XMPP service and a CPIM service.
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:
When sending a presence notification from CPIM to XMPP:
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 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:
When sending an unsubscribe command from CPIM to XMPP:
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.
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:
When sending a fetch request from CPIM to XMPP:
| TOC |
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].
| TOC |
| [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. |
| TOC |
| 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/ |
| T. Bamonti | |
| Jabber, Inc. | |
| 1899 Wynkoop Street, Suite 600 | |
| Denver, CO 80202 | |
| US | |
| EMail: | tbamonti@jabber.com |
| URI: | http://www.jabber.com/ |
| TOC |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.