TOC 
Network Working GroupJ. Miller
Internet-DraftP. Saint-Andre
Expires: December 20, 2002Jabber 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.



 TOC 

Table of Contents




 TOC 

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.



 TOC 

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    |
+-------------+         +-------------+         +--------------+
        


 TOC 

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:

When sending messages from CPIM to XMPP:

3.2.2 Exceptions

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).

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 <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 

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:

When sending a subscription request from CPIM to XMPP:

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:

Exceptions between an XMPP service and a CPIM service are mapped as follows:

4.2.1.3 Completing the Subscribe Operation

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:

4.2.2 The Notify Operation

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:

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 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:

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.

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 

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].



 TOC 

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.


 TOC 

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/
  
  T. Bamonti
  Jabber, Inc.
  1899 Wynkoop Street, Suite 600
  Denver, CO 80202
  US
EMail:  tbamonti@jabber.com
URI:  http://www.jabber.com/


 TOC 

Full Copyright Statement

Acknowledgement