[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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 <body/> 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 <body/> 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 <error/> 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 <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:

   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 <error/> 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 <error/> 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 <error/> 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,
        <http://www.ietf.org/rfc/rfc2779.txt>.

   [3]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000, <http://
        www.ietf.org/rfc/rfc2778.txt>.

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