Network Working Group B. Campbell Internet-Draft J. Rosenberg Expires: April 25, 2003 dynamicsoft J. Peterson NueStar October 25, 2002 Instant Message Transport Sessions using the CPIM Message Format. draft-campbell-simple-cpimmsg-sessions-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 April 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. Each message can be sent independently using the SIP MESSAGE method, or messages can be associated into sessions that are initiated using SIP. The first approach is often referred to as pager-mode messaging, due to its similarity to the behavior of two way pager devices. The second Campbell, et al. Expires April 25, 2003 [Page 1] Internet-Draft CPIM Transport Sessions October 2002 approach is often called session-mode messaging, or simply message sessions. This document describes a message session mechanism based on the Common Presence and Instant Messaging message format. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CPIM Transport Sessions . . . . . . . . . . . . . . . . . . 3 3. Use of CPIM Message Format . . . . . . . . . . . . . . . . . 3 4. Session Creation . . . . . . . . . . . . . . . . . . . . . . 4 4.1 M-Line Format List . . . . . . . . . . . . . . . . . . . . . 4 4.2 Determining the Local and Remote URIs . . . . . . . . . . . 4 4.3 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 5 5. Sending Messages . . . . . . . . . . . . . . . . . . . . . . 5 6. Receiving Messages . . . . . . . . . . . . . . . . . . . . . 6 6.1 Message Framing . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Parsing the Received Message . . . . . . . . . . . . . . . . 6 6.3 Confirmation of Receipt . . . . . . . . . . . . . . . . . . 6 6.3.1 Syntax for message/im-delivery-status . . . . . . . . . . . 7 7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 8 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 10 Informational References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 Campbell, et al. Expires April 25, 2003 [Page 2] Internet-Draft CPIM Transport Sessions October 2002 1. Introduction The SIP MESSAGE method specification [8] defines how to send instant messages directly inside SIP [3]. These instant messages follow a model similar to that of a two way pager device, i.e. there is not a protocol relationship between one message and another. An alternative model is the session model [1]. In this model, a SIP invitation is used to establish an instant messaging session. This session can provide context to the messages, for features such as sequencing and session key establishment. The SIMPLE IM Session document [1] describes how to use SIP to establish message sessions in general. That document does not however, specify a message session transport mechanism. This document describes such a mechanism based on the CPIM message format [2]. It uses TCP or TLS as the underlying transport. This document also describes extensions to the CPIM format for purposes of transaction identification. The mechanism described herein allows for sessions to be established directly between endpoints, as well as the use of intermediaries. It provides a mechanism for end-to-end protection of message contents. 2. CPIM Transport Sessions A CPIM transport session consists of a series of CPIM message format messages [2] exchanged over TCP or TLS. These sessions may be established using the Session Initiation Protocol as described in [1] . A TCP or TLS connection established to carry a CPIM transport session may be reused for other CPIM transport sessions. In particular, each connection is bi-directional and may carry more than one session at a time. 3. Use of CPIM Message Format The CPIM message format [2] uses a MIME based format, with additional meta-data headers. Several meta-data headers are defined in the CPIM message specification. Additionally, the cpim format makes use of an outer MIME envelope, which always has a content-type of "message/ cpim". The payload inside a CPIM message is expressed in MIME as well, with its own MIME headers. When used in an instant message session, the From and To meta-data headers are used to identify the session. There is no expectation that these headers actually identify the participants in the session- -they are used only as tokens to identify the session itself. Effectively, the recipient of the message is not a user, but a session context established by SIP. Campbell, et al. Expires April 25, 2003 [Page 3] Internet-Draft CPIM Transport Sessions October 2002 CPIM transport sessions use an extension header known as MsgID. MsgID serves as a message identifier for purposes of delivery confirmation. MsgID is an integer value unique at the scope of session and direction, i.e. the local MsgID of one endpoint is independent of that of the other. An endpoint increments its by one MsgID for each message sent on in the session. 4. Session Creation CPIM transport session parameters are negotiated using SDP offer/ answer exchanges as described in the SIMPLE IM Sessions specification [1]. TCP and TLS connections are also managed in accordance with that specification. Note that a single connection may support more than one session. Every session has one associated connection, but a connection may have zero of more associated sessions. 4.1 M-Line Format List The IM Session specification states that the protocol parameter indicates the session mechanism and transport protocol. For CPIM transport sessions, this value must be "cpim/tcp" for TCP, or "cpim/ tls" for TLS. Format list entries are used to designate payload types that the endpoint is willing to accept. These entries take the form of the MIME type of the payload. An endpoint MUST be willing to receive payloads of type text/plain, and MAY be willing to receive other types. Even though text/plain support is required, the format list MUST contain an explicit entry for it. For example, an endpoint is willing to accept HTML in addition to the required plain text might create an m-line like the following: m=message 8937 cpim/tls text/plain text/html 4.2 Determining the Local and Remote URIs Each endpoint proposes its local URI, and gets the remote URI from the SDP sent by the opposite endpoint. Each endpoint MUST include its proposed URI in an SDP a-line, with a parameter type of "uri". For example: a=uri:im:e9eu7fe@foo.example.com CPIM transport sessions use the URIs only for session identification. They are not used for determining the address of the opposite endpoint. The URI represents the message transport session context. If an endpoint wishes to participate in multiple simultaneous sessions, it MUST provide different URIs for each session. The URI MUST be globally unique, in order to allow the session relay Campbell, et al. Expires April 25, 2003 [Page 4] Internet-Draft CPIM Transport Sessions October 2002 mechanism described later in this document. 4.3 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a CPIM transport session. A offers the following session description containing the following lines: c=IN IP4 alice.example.com m=message 7394 cpim/tcp text/plain a=direction:both a=uri:im:2s93i9@alice.example.com Endpoint B chooses to participate, but prefers to initiate the connection. B answers with a media description including the following lines: c=IN IP4 bob.example.com m=message 8493 cpim/tcp text/plain a=direction:active a=uri:im:849ro3@bob.example.com B then opens a TCP connection to alice.example.com:7394, and can send CPIM transport session messages with a remote URI of im:2s93i9@alice.example.com and a local URI of im:849ro3@bob.example.com. And of course, A can send messages on the same connection with the same URIs, swapping local and remote. 5. Sending Messages When an endpoint wishes to send an instant message on a CPIM transport session, it constructs a CPIM message. This message MUST contain a To meta-data header value equal to the remote URI, and a From meta-data header value, which SHOULD be used to identify the sender, but MAY be set to some other value for purposes of anonymity . The endpoint MUST insert a MsgID meta-data header. If this is the first message that the endpoint has sent on this particular session, it MUST initialize the local MsgID the value of 1. Each subsequent message MUST increment the MsgID by one. The message MAY include a DateTime header. This can be used to simply convey the sending time of the message, and can also be used to provide additional uniqueness in the message. Furthermore, a message MAY contain a Subject header. This is distinct from the Subject of the SIP invitation, which contains the purpose of the session. The CPIM Subject header indicates the subject of the specific message, and can provide a form of threading Campbell, et al. Expires April 25, 2003 [Page 5] Internet-Draft CPIM Transport Sessions October 2002 within the session. The endpoint MUST also set the outer MIME envelope. This MUST include exactly two MIME headers. The first MUST be a content-type header with a value of "message/cpim". The second MUST be a content- length header in the outer MIME envelope, which specifies the length of the entire contents of the outer envelope. This is made up of the total length of all meta-data headers, the inner separator line, all inner MIME headers, the inner separator line, and the inner MIME payload. The endpoint then MUST place the message payload into the inner MIME body, with the appropriate MIME headers. These MUST include a Content-Type header, and MAY include other MIME headers. Once the message is constructed, the endpoint MUST send the message on the connection associated with this session. 6. Receiving Messages When an endpoint receives data on the connection associated with one or more sessions, it first attempts to frame the message. 6.1 Message Framing The receiving endpoint MUST discard any data prior to a first outer MIME header. This will always be a Content-type header with a value of "message/cpim". The second header will be a Content-length header. The receiver determines the length of the message from the outer Content-length header. 6.2 Parsing the Received Message Once a message is framed, the receiving endpoint MUST read the To and From meta-data headers. If these do not match an existing session that is associated with the connection, the receiver SHOULD discard the message in its entirety. Once the receiver has determined that the message matches a session, it renders the inner body to the session user, following normal MIME rules. The receiver can group the messages into conversations based on the session identifiers, and can use the MsgID to indicate ordering, if so desired. 6.3 Confirmation of Receipt Under normal operation, each message sent from one user to another is unacknowledged beyond any transport layer acknowledgements. However, Campbell, et al. Expires April 25, 2003 [Page 6] Internet-Draft CPIM Transport Sessions October 2002 in the case of intermediaries, transport layer acknowledgements are not sufficient to determine the final status of the delivery of an IM to the recipient. To support such an acknowledgement, this specification provides a delivery status confirmation function. A UA indicates its desire to receive delivery confirmations by including the MIME content type of a confirmation format in its list of supported message types. All UA MUST, at a minimum, support message/im-delivery-status, described below. A UA that wishes to receive delivery confirmations MUST explicitly include message/im- delivery-status in the list of supported message types. It MAY also include other message types. If a UA has requested confirmations by including at least one confirmation format in its list of supported message types, its peer MUST generate a delivery status report for each message received in the session. The format of the delivery status report MUST be one of the formats listed in the supported message types by the opposite UA. The only exception is for message confirmations themselves. That is, a UA MUST NOT send a message confirmation for the receipt of a message confirmation. When a confirmation report is sent, it is sent as would any other message within the session. This means that it is encapsulated in the message/cpim wrapper, it will have a MsgID one higher than the previous message transmitted, and the To and From meta-data fields will be set as described above. The format of the mesage/im-delivery-status borrows from RFC 1894 [6], but is simpler in structure because of the differences between session-mode messaging and the pager-like architecture of email. This new syntax is described in Section Section 6.3.1. Each IM delivery status message MUST include an Original-MsgID header field, which contains the MsgID of the message begin acknowledged. The Action and Status fields are optional, and their semantics are defined in RFC 1894 [6] and RFC 1893 [5]. [Open Issue: do we want to reuse these? RFCs 1893/4 really refer to status codes from a relay. Session mode messaging is end-to-end. However, an endpoint can be a relay (such as an SMS gateway) or even an expander (a conference server). Therefore, the semantics of the various values don't quite match our use cases.] [Open Issue: For an IM conference server, do we want to support per- recipient confirmations, or just one confirmation from the server? ] 6.3.1 Syntax for message/im-delivery-status A message of type message/im-delivery-status contains a series of name/value pairs separated by CRLF. Campbell, et al. Expires April 25, 2003 [Page 7] Internet-Draft CPIM Transport Sessions October 2002 im-status = *header-field header-field = (original-msgid / action / status / extension-header) CRLF original-msgid = "Original-MsgID" HCOLON *DIGIT action = see RFC 1894 Status = see RFC 1894 7. Intermediaries The CPIM transport session mechanism can support the use of session aware message relays. While end-to-end sessions are encouraged, there are a number of applications where such relays may be needed. For example, such intermediaries may serve as firewall and NAT traversal points. They may also server as policy enforcement points. +--------+ +--------+ | | SIP | | | P1 +-----------------+ P2 | /| | | |\ / +------+-+ +-+------+ \ SIP SIP / | | \ / |Control | \ / |Interface | \ / | | \ +----/---+ +-+------+ +------+-+ +----\---+ | | | | | | | | | C1 +-------+ R1 +-------+ R2 +------+ C2 | | | CPIM | | CPIM | | CPIM| | +--------+ +--------+ +--------+ +--------+ The above diagram shows an example of message relays controlled by SIP proxy servers. The SIP session setup crosses through proxies P1 and P2. Each proxy MAY rewrite the C-line address and the M-line port to refer to its associated relays address and port, and request the associated relay to install the relevant session state. The proxies MAY also re-write the protocol parameter on the M-line. The re-written protocol parameter MUST designate a transport otherwise supported by the CPIM transport session mechanism. If the SDP includes a direction attribute including a source address and port, the proxy MUST also re-write this to the source address and port the relay will use. Proxies MUST NOT change any other field in the SDP. R1 and R2 are likely to be traversed by any number of sessions. For reasons of congestion-safety, it is desirable to share a small number of connections between all such sessions. Therefore message session relays MUST be capable of sharing a connection between multiple sessions. Such relays MUST NOT use the port number to de-multiplex Campbell, et al. Expires April 25, 2003 [Page 8] Internet-Draft CPIM Transport Sessions October 2002 sessions, rather they MUST identify sessions using the normal CPIM transport session identification fields, that is, the From and To meta-data headers. The control interface between the controlling proxies and the message session relays is not in scope for this document. In many cases, the proxy and relay functions will simply be collocated. 8. Definitions [To do: We probably need formal definitions for MsgID, and for the URI a-line attributes.] 9. Security Considerations All IM session protocols must be compliant with the IM security requirements in RFC2779 [10]. The CPIM message format [2] contains its own security considerations, compliant with RFC2779, for providing end-to-end authentication, confidentiality, and integrity properties for CPIM messages. All implementations of this specification MUST follow the normative security requirements described in that specification. Note that the baseline SIP IM sessions specification [1] contains Security Considerations for the negotiation of session keys via SDP [4]; implementations of this specification MUST be able to derive session keys for the aforementioned security mechanisms from the procedures described in that specification [1]. [Open Issues: We need to reconsile the session key requirement of the IM Sessions draft with the S/MIME usage of message/cpim. Is it feasible to use a session key negotiated in the SDP exchange as either a symmetric KEK or a CEK in S/MIME? Is TLS sufficient if intermediaries are not involved? 10. IANA Considerations [To do -- if we define a CPIM name space for MsgID. Also, I am unsure if we need to register the URI a-line attribute] The receipt confirmation message format (message/im-delivery-status) will require IANA registration. 11. Open Issues Do we really want to use the RFC 1894 and RFC 1893 meanings for Action and Status field in delivery status report messages?. Also, would a conference server or similar device be expected to pass Campbell, et al. Expires April 25, 2003 [Page 9] Internet-Draft CPIM Transport Sessions October 2002 delivery reports back to the message originator? The intermediary section will change significantly. We do not wish to encourage implementers to allow proxies to modify SDP. Rohan has suggested a mechanism to use something conceptually similar to the SIP Route header. Does that belong in this draft, or in a separate document? The security considrations section needs more work. There are several relevant controversies. First, how do we reconcile the idea of a session key negotiated in the SDP with the S/MIME requirements of the message/cpim format. Second, do we really wish to use MIKEY for session key negotiation, or can we get by with something simpler? The draft needs more examples and formal definitions. 12. Contributors The following people contributed substantially to this document: Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Jonathan Rosenberg Robert Sparks Dean Willis Normative References [1] Campbell, B. and J. Rosenberg, "Instant Message Sessions in SIMPLE", draft-campbell-simple-im-sessions-00 (work in progress), October 2002. [2] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-06 (work in progress), February 2001. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. Campbell, et al. Expires April 25, 2003 [Page 10] Internet-Draft CPIM Transport Sessions October 2002 [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. Informational References [7] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-03 (work in progress), August 2002. [8] Campbell, B. and J. Rosenberg, "Session Initiation Protocol Extension for Instant Messaging", draft-ietf-sip-message-07 (work in progress), September 2002. [9] Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf- msec-mikey-04 (work in progress), August 2002. [10] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Jon Peterson NueStar 1800 Sutter St. Suite 570 Concord, CA 94520 Campbell, et al. Expires April 25, 2003 [Page 11] Internet-Draft CPIM Transport Sessions October 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, et al. Expires April 25, 2003 [Page 12]