Internet Engineering Task Force B. Campbell
Internet-Draft J. Rosenberg
Expires: August 2, 2002 dynamicsoft
Feb. 2002
CPIM Mapping of SIMPLE Presence and Instant Messaging
draft-ietf-simple-cpim-mapping-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 August 2, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Campbell & Rosenberg Expires August 2, 2002 [Page 1]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
Abstract
The SIMPLE work group has defined a SIP events package for
distribution of presence information. It has also proposed a MESSAGE
extension for the transport of instant messages. This document
describes how those mechanisms map to the abstract CPIM service, in
order to interoperate with other CPIM compliant presence and instant
messaging services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The CPIM Abstract Gateway Service . . . . . . . . . . . . . . 3
3. Mapping SIMPLE Presence to CPIM . . . . . . . . . . . . . . . 4
3.1 Mapping SUBSCRIBE reqests to CPIM . . . . . . . . . . . . . . 4
3.2 Mapping CPIM subscriptions to SIP . . . . . . . . . . . . . . 6
4. CPIM Mapping for Instant Messages . . . . . . . . . . . . . . 8
4.1 Mapping SIP MESSAGE requests to CPIM . . . . . . . . . . . . . 8
4.2 Mapping CPIM operations to SIP . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 URL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
Campbell & Rosenberg Expires August 2, 2002 [Page 2]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
1. Introduction
Common Presence and Instant Messaging (CPIM)[2] describes the
semantics of an abstract presence and instant messaging service.
Concrete service protocols, such as SIMPLE, that conform to the CPIM
should be able to interoperate with each other using CPIM compliant
gateways.
The SIMPLE work group designed SIP[1] based protocols for the
distribution of instant messages and presence documents. Presence[3]
may be distributed using a SIP event[5] package. Instant Messages
may be transferred using the MESSAGE[4] method extension to SIP.
This document describes how the SIMPLE presence and instant message
mechanisms map to the abstract CPIM service.
2. The CPIM Abstract Gateway Service
A SIMPLE based service may interoperate with other CPIM compliant
services through the use of a gateway. This document describes a
gateway to an abstract CPIM service. In any actual implementation,
this gateway would convert SIMPLE to some other concrete protocol.
As long as that protocol also maps to CPIM, the gateway semantics
will be the same.
For the purposes of this document, we show the CPIM abstract gateway
as handling both presence and instant messages. In a concrete
implementation this may or not be true--a single gateway might
handle both, or there might be a separate gateway for each service.
+-------------+
| |
| SIP to CPIM |
| Conversion |
| |
SIMPLE | | CPIM Service
<-------------->| | <--------------->
| |
| |
| |
| |
| |
| |
+-------------+
Campbell & Rosenberg Expires August 2, 2002 [Page 3]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
3. Mapping SIMPLE Presence to CPIM
This section defines how a SIP SUBSCRIBE and NOTIFY requests may be
converted to CPIM, and how CPIM messages are converted to SIP for
presence. SIP to CPIM conversion occurs when a SIP system sends a
SUBSCRIBE request that contains a pres URL or SIP URL that
corresponds to a user in a domain that runs a different presence
protocol. CPIM to SIP involves the case where a user in a different
protocol domain generates a subscription that is destined for a user
in a SIP domain.
Note that the process defined below requires that the gateway store
both transaction and subscription state. The transaction state is
needed to map the SIP transaction identifiers to the CPIM transID
value. Subscription state is needed to store the SIP dialog
information associated with the subscription.
From the SIP perspective, the CPIM gateway is an endpoint, that is,
it is the terminating point for the SIP transactions and dialogs.
The gateway can be thought of as a b2bua, except that the opposite
side implements the abstract CPIM service (or some concrete CPIM
compliant service.)
3.1 Mapping SUBSCRIBE reqests to CPIM
The SUBSCRIBE process begins when the CPIM gateway receives a SIP
SUBSCRIBE requests. First, the gateway MUST determine if the request
is an initial request or a mid-dialog request. If it is a mid-dialog
request, the gateway MUST treat it as a refresh. Note that since
CPIM does not allow duplicate subscriptions. the gateway MUST reject
any new SUBSCRIBE request that would result in watcher and target
identies that match an existing subscription with a 486 response.
Otherwise, the The gateway generates a corresponding CPIM
subscription request message in the following fashion:
o Copy the watcher identity from the SIP From header.If the From
header contains a SIP URL, the gateway converts it to a presence
URL by dropping any URL parameters and changing the scheme to
"pres".
This may not work. What if the SIP URL has no user name? Plus,
converting a URL back to a URN in this fashion may not do it
correctly
o Copy the Request-URI from the SUBSCRIBE request to the target
value of the CPIM message. This URL may also require conversion
to the "pres" scheme.
Campbell & Rosenberg Expires August 2, 2002 [Page 4]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
o Copy the Expires header from the SUBSCRIBE request to the
duration parameter in the CPIM message. If the Expires header is
specified in absolute time format, convert it into a delta-time
format. If the SUBSCRIBE request does not contain an Expires
header, choose a value based on local policy. If thereis no
policy to the contrary, this value SHOULD be one hour.
o Construct the transID parameter as a hash over the the
Request-URI, the Call-ID, the To URI, the From URI, the CSeq, and
the From tag.
The CPIM service then a "success", "failure", or "indeterminate"
response. If the CPIM gateway can determine immediately (that is,
quickly enough to avoid retransmissions on the part of the
requestor) that a subscription is sucessful, it returns a 200
response. If it can immediately determine the request is
unsuccessful, it generates a 603 response. If the result is
indeterminate, or cannot be determined immediately, the gateway
sends a 202 response.
In the event of a successful response, the gateway copies the
duration value into an Expires header of the SIP response. The
gateway adds a Contact header to the SIP response which contains the
target identity.
When the CPIM system generates a notification request, the gateway
first checks that the target and watcher values match an existing
subscription. If no match exists, the gateway ignores the request.
If a match does exist, the gateway constructs and sends a SIP NOTIFY
request according standard procedures for mid-dialog requests. In
additon, the gateway populates the request in the following manner:
o Copy the watcher identity to the From header.
o Copy the target identity to the To header. (The Request-URI comes
from the Contact header in the original subscribe.)
o Copies the presence information into the body of the NOTIFY
request.
CPIM has no concept of responses to notifications, so for the most
part the gateway simply consumes responses to SIP NOTIFY requests.
However, if such a response indicates a failure of the NOTIFY
request, the gateway SHOULD cease forwarding future NOTIFY requests
from the CPIM service for the associated subscription. If the NOTIFY
response was a 481, then the gateway MUST cease sending notifies for
the associated subscription. If the gateway ceases forwarding of
notifications on a subscription, it SHOULD initiate an unsubscribe
request to the CPIM service.
Campbell & Rosenberg Expires August 2, 2002 [Page 5]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
The gateway handles subscription request refreshes simularly to
initial subscription requests, except that the gateway will already
have dialog state stored for the subscription.
The gateway handles an unsubscribe request, that is, a SIP SUBSCRIBE
request with an Expires of zero, in exactly the same manner as a
subscription refresh. This will result in a CPIM subscribe request
with a duration or zero, which results in the removal of the
subscription.
The CPIM response to the unsubscribe attempt is either success or
failure. In the case of success, the gateway returns a SIP 2XX class
response. In the case of failure, the gateway returns a 6XX class
response. The responses are constructed in the same manner as above.
The gateway should remove any subscription state, if present.
3.2 Mapping CPIM subscriptions to SIP
The gateway maps CPIM subscriptions to SIP when a CPIM subscription
request arrives at the gateway.
The gateway coverts the subscription request into a SIP SUBSCRIBE
request. The gateway determines if this request is for an existing
subsciption by comparing the target and watcher to those of existing
subscriptions. If the there is a match, the request is for the
refresh an existing subscription.
For a new subscription, the gateway constructs a SUBSCRIBE request
in the following manner:
o Set the From header to the watcher value of the CPIM request.
o Set the To header and the Request-URI to the target value of the
CPIM request.
o Set the Expires header to the duration value from the CPIM
request.
The gateway then sends the SUBSCRIBE request following normal SIP
rules.
For a subscription refresh, the gateway determines the subscription
dialog that matches the target and watcher in the CPIM request. It
generates the SIP SUBSCRIBE request in much the same manner as for a
new subscription, except that it must follow the normal SIP rules
for a mid-dialog request.
When the gateway receives the SIP response, it constructs a response
to the CPIM system in the following manner:
Campbell & Rosenberg Expires August 2, 2002 [Page 6]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
o Copy the Expires header to the duration value, converting to
delta-time if required.
o Determine the transID from the stored transaction state.
o For a 202 response, make the status "indeterminate." For any
other 2XX class response, make the status "success." For any
non-2XX class final response, make the status "failure."
If the subscription was successful, the gateway MUST establish
subscription state. This state maps the SIP dialog identifying
information to the combination of CPIM watcher and target identities.
If the gateway receives an unsubscribe request from the CPIM
service, it checks whether the subscription state exists based on
the target and watcher value. If the subscription does exist, the
gateway constructs a SUBSCRIBE request as described above, but with
an Expires header of zero. If the subscription did not exist, the
gateway returns a failure response to the CPIM service.
When the gateway receives a SIP NOTIFY request, it first determines
if the request matches an existing dialog. If not, it returns a 481
response. If the request matches an existing subscription dialog,
the gateway constructs a CPIM notification request in the following
fashion:
o Set the watcher value to the Request-URI.
o Set the target to the URI in the From header.
o Generate a unique transID.
The gateway then generates a 200 OK response to the NOTIFY request.
Note that the CPIM service does not send a response to a
notification request. The gateway SHOULD treat all notifies that
match an existing dialog as successful
Note that a SIP NOTIFY can indicate the subscription has been
terminated, by the inclusing of a Subscription-State header value of
"terminated." CPIM has no similar concept. Therefore the gateway has
no mechanism by which it can inform the CPIM service that a
subscription has been terminated early.
If early termination occurs, the gatway MAY choose to simply drop
state for the subscription. It MAY generate a NOTIFY request
containing a presence body indicating that the current presence
state of the presentity is no longer known (the mechanism for which
is out of scope for this document). It MAY choose to generate a new
SIP SUBSCRIBE request.
Campbell & Rosenberg Expires August 2, 2002 [Page 7]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
4. CPIM Mapping for Instant Messages
This section describes how the gateway may map instant messages
between a SIPbased- service and a CPIM service. The mapping of IMs
is much simpler than presence, due to the fact that IMs do not
initiate a SIP dialog.
4.1 Mapping SIP MESSAGE requests to CPIM
When the gateway receives a SIP MESSAGE request, it generates a CPIM
message operation in the following manner:
o Create the source identity based on the sender's credentials or
From header in the case of an unauthenticated message. However,
the gateway SHOULD authenticate the MESSAGE request. If the
request is authenticated, the source identity MUST be the
authenticated credentials. If the sender's identity is not
authenticated, then the gateway SHOULD indicate that fact in a
display-name or comment section of the source parameter. Note
that this may require converting the URL scheme from "sip:" to
"im:", following the same procedures as described in the presence
mapping section.
o Copy the Request-URI to the destination parameter. Note that this
may also require URL conversion.
o Generate a transID value, maintaining sufficient local
transaction state to associate the CPIM response with the SIP
request.
o Copy the body from the SIP MESSAGE request into the body of the
CPIM message. If the body has a MIME type of message/cpim, it
MUST be sent unchanged. Any other type MUST be imbedded into a
message/cpim body part.
If the CPIM service responds with a "success", the gateway SHOULD
generate a 200 response. If the CPIM service responds with
"failure", the gateway SHOULD return a 603 response. If the gateway
has a local policy to neither confirm or deny delivery of IMs, it
MAY return a 202 to all requests. If the gateway UAS cannot
determine the results of the message operation in a short enough
time to avoid a SIP transaction timeout, it MUST return a 202
accepted response.
4.2 Mapping CPIM operations to SIP
When a gateway maps a CPIM message operation to SIP, it generates a
SIP MESSAGE request according to the following procedure:
Campbell & Rosenberg Expires August 2, 2002 [Page 8]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
o Copy the destination identity to the Request-URI and the To
header, converting the URL schemes if required.
o Copy the CPIM body into the SIP body unchanged.
o Copy the transID to the SIP From tag.
o Establish local transaction state.
When the gateway receives a final response to the SIP request, it
generates the CPIM response in the following manner:
o If the response was a 202, set the status to "indeterminate".
o If the response was any other 2XX class response, set the status
to "success."
o If the response was any 4XX,5XX,or 6XX class response, set the
status to "failure."
o Copy the From tag to the transID.
5. Security Considerations
End-to-end security concerns for instant messaging were a primary
driving force behind the creation of message/cpim. Application
designers needing end-to-end security should study that work
carefully. In all cases, gateways MUST NOT modify a message/cpim
body part in any way.
There are several cases in this document where a gateway determines
an IM source or watcher identity from a SIP message. While in some
cases, the From header is the only source of such information, the
From header is not the best choice. In general, gateways SHOULD
authenticate the sender's identity in some manner. The nature of
this authentication is beyond the scope of this document. If the
gateway authenticates the sender's identity, it MUST determine the
source or watcher from the authenticated credentials instead of the
From header.
6. Open Issues
6.1 URL Mapping
This document currently proposes a trivial conversion between SIP
URLS and URLs with the schema of "pres" or "im". This needs
considerably more thought.
Campbell & Rosenberg Expires August 2, 2002 [Page 9]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
7. Acknowledgments
The authors would like to thank the following people for their help
in the creation of this document.
Adam Roach dynamicsoft
Robert Sparks dynamicsoft
and
All authors of the SIMPLE presence and IM drafts
References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne,
G., Rose, M., Rosenberg, J., Sparks, R. and H. Sugano, "A
Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-cpim-02 (work in progress), November 2001.
[3] Rosenberg, et al, J., "SIP Extensions for Presence",
draft-ietf-simple-presence-04 (work in progress), November 2001.
[4] Rosenberg, J., Willis, D., Sparks, R., Schulzrinne, H., Lennox,
J., Huitema, C., Aboba, B., Gurle, D. and D. Oran, "SIP
Extensions for Instant Messaging", draft-ietf-sip-message-00
(work in progress), November 2001.
[5] Roach, A., "SIP-Specific Event Notification",
draft-ietf-sip-events-02 (work in progress), February 2002.
Authors' Addresses
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
email: bcampbell@dynamicsoft.com
Campbell & Rosenberg Expires August 2, 2002 [Page 10]
Internet-Draft SIMPLE CPIM mapping Feb. 2002
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Campbell & Rosenberg Expires August 2, 2002 [Page 11]
Internet-Draft SIMPLE CPIM mapping Feb. 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.
Campbell & Rosenberg Expires August 2, 2002 [Page 12]