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]