[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/