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

Versions: 00 01

SIMPLE Working Group                                         B. Campbell
Internet-Draft                                              J. Rosenberg
Expires: April 25, 2003                                      dynamicsoft
                                                        October 25, 2002


                   Instant Message Sessions in SIMPLE
                  draft-campbell-simple-im-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

   The SIP MESSAGE method is used to send instant messages, where each
   message is independent of any other message.  This is often called
   pager-mode messaging, due to the fact that this model is similar to
   that of most two-way pager devices.  Another model is called session-
   mode.  In session-mode, the instant messages are part of a media
   session that provides ordering, a security context, and other
   functions.  This media session is established using a SIP INVITE,
   just as an audio or video session would be established.

   This document describes a method of initiating and managing message
   sessions using SIP.



Campbell & Rosenberg     Expires April 25, 2003                 [Page 1]


Internet-Draft             SIMPLE IM Sessions               October 2002


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation for Session-mode Messaging  . . . . . . . . . . . .  3
   3.  Message Session Mechanisms . . . . . . . . . . . . . . . . . .  4
   4.  SDP Offer-Answer Exchanges for Message Sessions. . . . . . . .  5
   4.1 Use of the SDP M-line  . . . . . . . . . . . . . . . . . . . .  5
   4.2 SDP Extensions for Connection Oriented Media . . . . . . . . .  6
   4.3 Session Parameters . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Example SDP Exchange . . . . . . . . . . . . . . . . . . . . .  6
   6.  Baseline Implementation Requirements . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  8
       Normative References . . . . . . . . . . . . . . . . . . . . .  8
       Informational References . . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
































Campbell & Rosenberg     Expires April 25, 2003                 [Page 2]


Internet-Draft             SIMPLE IM Sessions               October 2002


1. Introduction

   The MESSAGE [7] extension to SIP [3]  allows SIP to be used to
   transmit instant messages.  Instant messages sent using the MESSAGE
   method are normally independent of each other.  This approach is
   often called pager-mode messaging, since it follows a model similar
   to that used by many two-way pager devices.  Pager-mode messaging
   makes sense for instant message exchanges where a small number of
   messages occur.

   There are also applications in which it is useful for instant
   messages to be associated together in some way.  For example, a user
   may wish to join a text conference, participate in the conference for
   some period of time, then leave the conference.  This usage is
   analogous to regular media sessions that are typically initiated,
   managed, and terminated using SIP.  We commonly refer to this model
   as session-mode messaging.

   One of the primary purposes of SIP is the management of media
   sessions.  Session-mode messaging can be thought of as a media
   session like any other.  This document describes a method to use SIP
   to manage message sessions.  This document does not propose an actual
   message session mechanism; there may any number of mechanisms that
   are appropriate for different applications and environments.

2. Motivation for Session-mode Messaging

   Message sessions offer several advantages over pager-mode messages.
   For message exchanges that include more than a small number of
   message transactions, message sessions offer a way to remove
   messaging load from intervening SIP proxies.  For example, a minimal
   session setup and teardown requires one INVITE/ACK transaction, and
   one BYE transaction, for a total of 5 SIP messages.  Normal SIP
   request routing allows for all but the initial INVITE transaction to
   bypass any intervening proxies that do not specifically request to be
   in the path for future requests.  In the default usage, instant
   messages themselves are sent end-to-end, without touching intervening
   SIP proxies.

   Each pager mode message involves a complete SIP transaction, that is,
   a request and a response.  Any pager-mode message exchange that
   involves more than 2 or 3 MESSAGE requests will generate more SIP
   requests than a minimal session initiation sequence.  Since MESSAGE
   is typically used outside of a SIP dialog, these requests will
   typically traverse the entire proxy network between the endpoints.

   Due to network congestion concerns, the MESSAGE method has
   significant limitations in message size, a prohibition against



Campbell & Rosenberg     Expires April 25, 2003                 [Page 3]


Internet-Draft             SIMPLE IM Sessions               October 2002


   overlapping requests, etc.  Much of this has been required because of
   perceived limitations in the congestion-avoidance features of SIP
   itself.  Work is in progress to mitigate these concerns.

   However, session-mode messages are always sent over a reliable,
   congestion-safe transport.  Therefore, there are no restrictions on
   message sizes.  There is no requirement to wait for acknowledgement,
   so that messages can be overlapped.

   Message sessions allow greater efficiency for secure message
   exchanges.  The SIP MESSAGE request inherits the S/MIME features of
   SIP, allowing a message to be signed and/or encrypted.  However, this
   approach requires public key operations for each message.  With
   session-mode messaging, a session key can be established at the time
   of session initiation.  This key can be used to protect each message
   that is part of the session.  This requires only symmetric key
   operations, and no additional certificate exchanges are required
   after the initial exchange.  The establishment of the session key is
   done using standard techniques that apply to voice and video, in
   addition to instant messaging.

   Finally, SIP devices can treat message sessions like any other media
   sessions.  Any SIP feature that can be applied to other sorts of
   media sessions can equally apply to message sessions.  For example,
   conferencing [9], third party call control [10], call transfer [11],
   QoS integration [12], and privacy [13] can all be applied to message
   sessions.

   Messaging sessions can also reduce the overhead in each individual
   message.  In pager-mode, each message needs to include all of the SIP
   headers that are mandated by RFC 3261.  [3] However, many of these
   headers are not needed once a context is established for exchanging
   messages.  As a result, messaging session mechanisms can be designed
   with significantly less overhead.

3. Message Session Mechanisms

   This document does not define a specific message session mechanism.
   However, all message session mechanisms will need to address a common
   set of issues, resulting in several requirements which are discussed
   here.

   The first issue is congestion safety.  Instant messages can vary
   significantly in size, ranging from a few bytes to many megabytes.
   As a result, all message session mechanisms need to be congestion
   safe.  This issue is discussed at length in the MESSAGE method
   specification [7], and is the reason for the restrictions on the
   transport protocols used for the MESSAGE method.  These



Campbell & Rosenberg     Expires April 25, 2003                 [Page 4]


Internet-Draft             SIMPLE IM Sessions               October 2002


   considerations apply to message session mechanisms as well.  Any
   message session mechanism MUST be congestion-safe.

   Most media session types are currently based on the Real Time
   Transport Protocol [8].  While message sessions are managed much like
   any other media session, there are some significant differences in
   the underlying transport mechanisms.  RTP is designed for media types
   that take the form of time sequenced data, where the temporal
   relationship between packets is critical for proper playback.  In
   many cases, small amounts of packet loss are acceptable, as long as
   the temporal relationships can be maintained.

   Message sessions are different, in that while message ordering is
   important, the time between messages typically is not.  Reliable
   delivery of a message is much more important.  Of course, there are
   exceptions; one can imagine a media session type that transferred
   text as it was typed, with typing patterns preserved at the receiving
   end.  While this may be an interesting application, it falls outside
   of the class of message-oriented media session that are the subject
   of this document.

   Due to the different nature of message-oriented media sessions, and
   due to the network congestion concerns when sending instant message
   content over non-congestion controlled transports, message session
   mechanisms MUST use a reliable, congestion-safe network transport,
   such as TCP or SCTP.  Additionally, if multiple sessions exist
   between the same pair of devices, those devices SHOULD share the same
   connection across all of the sessions.

4. SDP Offer-Answer Exchanges for Message Sessions.

   This specification describes the usage of SDP for the establishment
   of instant messaging sessions.  This approach is used by all message
   sessions mechanisms.

4.1 Use of the SDP M-line

   The SDP m-line takes the following form:

      m=<media> <port> <protocol> <format list>

   For non-RTP media sessions, The media field specifies the top level
   MIME media type for the session.  For message sessions, the media
   field MUST have the value of "message".  The proto field MUST
   designate the message session mechanism and transport protocol,
   separated by a "/" character.  For example, "cpim/tcp".  The meaning
   of any entries in the format list MUST be described in the
   specification for the message session mechanism.  If said mechanism



Campbell & Rosenberg     Expires April 25, 2003                 [Page 5]


Internet-Draft             SIMPLE IM Sessions               October 2002


   supports multiple payload types, acceptable types SHOULD be described
   in the format list.

   The following example illustrates an m-line for a CPIM message
   session, where the endpoint is willing to accept payloads of plain
   text or HTML

      m=message 49232 cpim/tcp text/plain text/html


4.2 SDP Extensions for Connection Oriented Media

   SDP is typically used with UDP based media protocols.  In particular,
   base SDP does not provide support for negotiation of a two-way media
   session where a single connection is used in both directions, which
   is expected to be the normal model for message sessions.

   Therefore, endpoints wishing to establish message sessions MUST
   follow the COMEDIA [2] extensions to SDP, both for the negotiation of
   connection parameters, and for the establishment and management of
   the connections themselves.

4.3 Session Parameters

   Any additional session parameters that are to be negotiated in the
   SDP exchange MUST be communicated in the form of attribute lines.
   Such parameters specific to a particular message session mechanism
   MUST be defined in the specification of the mechanism

5. Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to a message session using the
   CPIM session mechanism.  [4] 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 text/html
           a=direction:active
           a=uri:im:849ro3@bob.example.com



Campbell & Rosenberg     Expires April 25, 2003                 [Page 6]


Internet-Draft             SIMPLE IM Sessions               October 2002


   B then opens a TCP connection to alice.example.com:7394.  A and B can
   begin to exchange instant messages on this connection using the CPIM
   message session mechanism.

6. Baseline Implementation Requirements

   To help ensure some degree of interoperability between endpoints
   supporting message sessions, any endpoint that supports message
   session as described in this document MUST support the  cpim message
   session mechanism [4] over TCP.  The CPIM session mechanism is a
   minimalist approach that is fairly inexpensive to support.  Such
   endpoints MAY support any number of other message session mechanisms.

7. Security Considerations

   Instant messages can contain very sensitive information.  As a
   result, as specified in RFC 2779 [5], instant messaging protocols
   need to provide for encryption, integrity and authentication of
   instant messages.  Any IM session mechanism MUST satisfy those
   requirements.

   Any protocol that is used as a messaging session transport protocol
   MUST  provide a means for encryption, authentication, and message
   integrity of the message.  This mechanism MUST operate even in the
   face of intermediaries in the transport protocol.  That is, it MUST
   provide a means of end-to-end security functions.  It is RECOMMENDED
   that any such mechanism make use of session keys that can be
   established through SIP, such as those created by MIKEY [6].

   Encryption, authentication and message integrity for messaging
   sessions can also be provided through the use of secure transport
   protocols, such as TLS.  It is RECOMMENDED that message session
   mechanisms make use of TLS, and that implementations SHOULD support
   it.

   The usage of SIP to establish an instant messaging session introduces
   additional security considerations.  Because SIP can be used to
   establish a session key for the messaging sessions, the SIP exchange
   itself needs to provide proper authentication in order for the
   instant messages themselves to be authenticated.  Authentication of
   SIP users is provided with S/MIME, and therefore, implementations
   MUST support S/MIME.

8. IANA Considerations

   This document does not require IANA registrations.





Campbell & Rosenberg     Expires April 25, 2003                 [Page 7]


Internet-Draft             SIMPLE IM Sessions               October 2002


9. Open Issues

   There is still ongoing discussion about the m-line format.  An
   alternative proposal is for the protocol field to only designate the
   network transport protocol, and the first entry in the format list
   designate the session mechanism to be used on that protocol.  This
   approach may make software layering easier, where a connection
   management layer need not be aware of the message session mechanism
   used.

   There is still controversy over the security considerations.  In
   particular, whether this draft should strongly the use of session
   keys negotiated in the SDP exchange, or leave that decision to the
   designers of any particular message session mechansim.

   The final version of this document needs more examples, and may
   require further formal definitions.

10. 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]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [2]  Yon, D., "Connection-Oriented Media Transport in SDP", draft-
        ietf-mmusic-sdp-comedia-04.txt (work in progress), July 2002.

   [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]  Campbell, B., "Instant Message Sessions using the CPIM Message
        Format.", draft-campbell-simple-cpimmsg-sessions-00.txt (work in
        progress), October 2002.

   [5]  Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
        Presence Protocol Requirements", RFC 2779, February 2000.



Campbell & Rosenberg     Expires April 25, 2003                 [Page 8]


Internet-Draft             SIMPLE IM Sessions               October 2002


   [6]  Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf-msec-
        mikey-04 (work in progress), August 2002.

Informational References

   [7]   Campbell, B. and J. Rosenberg, "Session Initiation Protocol
         Extension for Instant Messaging", draft-ietf-sip-message-07
         (work in progress), September 2002.

   [8]   Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", RFC
         1889, January 1996.

   [9]   Rosenberg, J. and H. Schulzrinne, "Models for Multi Party
         Conferencing in SIP", draft-ietf-sipping-conferencing-models-01
         (work in progress), July 2002.

   [10]  Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
         "Best Current Practices for Third Party Call Control in the
         Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work
         in progress), June 2002.

   [11]  Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc-
         transfer-05 (work in progress), July 2001.

   [12]  Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
         Resource Management and Session Initiation Protocol (SIP)", RFC
         3312, October 2002.

   [13]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work
         in progress), March 2002.


Authors' Addresses

   Ben Campbell
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: bcampbell@dynamicsoft.com








Campbell & Rosenberg     Expires April 25, 2003                 [Page 9]


Internet-Draft             SIMPLE IM Sessions               October 2002


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ  07936

   EMail: jdrosen@dynamicsoft.com












































Campbell & Rosenberg     Expires April 25, 2003                [Page 10]


Internet-Draft             SIMPLE IM 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 & Rosenberg     Expires April 25, 2003                [Page 11]


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