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

Versions: 00 01 02

SIMPLE WG                                                        R. Mahy
Internet-Draft                                       Cisco Systems, Inc.
Expires: August 1, 2004                                         Feb 2004


       Benefits and Motivation for Session Mode Instant Messaging
               draft-mahy-simple-why-session-mode-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 1, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   The SIMPLE working group describes one or more messages sent
   completely independently as "pager-mode" messages, whereas messaging
   associated with as part of a "session" with a definite start and end
   is called session mode messaging.  The SIMPLE community has received
   numerous comments and complaints from the larger IM community that
   session mode is more complex than pager mode messaging.  However,
   session mode messaging has a number of benefits which are not
   available in pager mode, but these benefits have not been widely
   articulated and this value is not well understood outside the SIP/
   SIMPLE community. This document attempts to describe the benefits of
   session mode, such as explicit rendezvous, integration with other
   media, direct client-to-client operation, and brokered privacy and
   security, in an accessible manner.



Mahy                     Expires August 1, 2004                 [Page 1]


Internet-Draft            Why Session Mode IM?                  Feb 2004


Table of Contents

   1. What are "Sessions" of Messages? . . . . . . . . . . . . . . .   3
   2. SIP Terminology  . . . . . . . . . . . . . . . . . . . . . . .   4
   3. Example: Choosing among multiple clients . . . . . . . . . . .   5
   4. Manipulating a Session . . . . . . . . . . . . . . . . . . . .   7
   5. Direct Client to Client Messaging  . . . . . . . . . . . . . .   8
   6. Security and Privacy Considerations  . . . . . . . . . . . . .   8
      Normative References . . . . . . . . . . . . . . . . . . . . .   9
      Informational References . . . . . . . . . . . . . . . . . . .  10
      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  11
      Intellectual Property and Copyright Statements . . . . . . . .  12







































Mahy                     Expires August 1, 2004                 [Page 2]


Internet-Draft            Why Session Mode IM?                  Feb 2004


1. What are "Sessions" of Messages?

   A series of related textual messages between two or more parties can
   be viewed as part of a session which has a definite start and end.
   This allows a communication user agent to offer a messaging session
   as one of the possible media types in a session using a session setup
   protocol such as SIP [1].  For instance, Alice may want to
   communicate with Bob. Alice doesn't know at the moment whether Bob
   has his phone or his IM client handy, but she's willing to use
   either. She sends an invitation to a session to the address of record
   she has for Bob, sip:bob@biloxi.com. Her invitation offers both voice
   and an IM session. The SIP services at biloxi.com forward the
   invitation to Bob at his currently registered clients. Bob accepts
   the invitation at his IM client and they begin a threaded chat
   conversation.

   This session model allows message sessions to be integrated into
   advanced communications applications with little to no additional
   protocol development. For example, during the above chat session, Bob
   decides Alice really needs to be talking to Carol. Bob can transfer
   Alice to Carol, introducing them into their own messaging session.
   Messaging sessions could be integrated into call-center and dispatch
   environments utilizing third-party call control and conferencing
   applications.

   The rendezvous and characteristics negotiation features of SIP can
   also be used to introduce peers in or broker among networks that have
   restricted server-to-server policies. A SIP invitation can contain an
   address and port of a messaging sessions server for the peer to
   connect to. It can also securely provide credentials or other data to
   be consumed by that messaging server. Further, the invitation could
   provide material to be used to encrypt the bodies of the messages
   transported in the chat session being established. In some cases, an
   endpoint can even create an ephemeral stand-alone IM server
   co-located with its client and use SIP to invite a peer to enter into
   a chat session at that server.  This configuration is very popular
   among wireless carriers and network providers and related standards
   organizations such as 3GPP.

   In other cases, the invitation would allow an endpoint's IM client to
   use a "home" IM server for policy enforcement and firewall traversal,
   establishing chat sessions over an existing connection, if present.
   The session management capabilities of SIP can be used to add
   concrete start and stop times to those sessions and, as above,
   provide material that the endpoints can use to secure the session.
   For example, Alice might be in a phone conference with Bob and
   decides she needs a text sub-channel. She is currently connected to
   an bulk messaging server through atlanta.com and Bob is currently



Mahy                     Expires August 1, 2004                 [Page 3]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   connected to another such server through biloxi.com. Alice and Bob
   don't know each other's screen names, address and port numbers or
   other connection details.  In fact Alice and Bob can be completely
   anonymous with respect to each other.  Alice can use SIP to invite
   Bob into a chat session, providing her temporary or ephemeral
   connection information (for example an XMPP jid or an MSRP URI: both
   described later), a thread to use, and maybe even a key to encrypt
   the messages with. Bob will provide his connection information in the
   SIP answer. Armed with this information, each of their endpoints can
   associate the resulting chat session with the phone call. Similarly,
   SIP can be used to invite peers to join ad-hoc or permanent groupchat
   sessions or conferences.

2. SIP Terminology

   SIP defines several logical roles. The most generic of these are the
   User Agent and Proxy roles. User Agents  originate and respond to SIP
   requests; Proxy Servers forward requests on toward their final
   destination. User Agents can communicate directly, or through any
   number of intermediate Proxy Servers. The SIP events framework also
   defines the concept of a State Agent, which is a User Agent which
   maintains event state for a particular resource. (For the presence
   event package, such a state agent is called a Presence Agent.  SIP
   supports subscriptions, notifications, and publications of such
   presence data.)

   SIP has three primary functions: as a rendezvous protocol, a
   subscription management protocol, and a session management protocol.
   The rendezvous aspects allow SIP Proxy Servers and User Agents to
   select the best possible set of ordered contacts for a given user or
   resource and try these contacts in parallel, in series, or in some
   appropriate combination.  This insures that the best contact or
   instance can be reached for each request. The subscription management
   aspect is straightforward and has already been discussed briefly
   above. SIP User Agents (UAs) also exchange session management
   requests which can include offer or answer session descriptions which
   are used to setup the media streams which constitute a session. These
   streams can include for example: RTP audio or video, IM transport
   streams, gaming sessions, and application sharing. Finally, SIP has
   facilities to further manipulate (combine, split, and move) these
   sessions.

   SIP can also send individual "page-mode" messages [2] from one UA to
   another, although sending large or frequent messages through SIP
   Proxies can have undesirable performance implications on real-time
   signaling sharing the same SIP connections. Likewise, sending
   page-mode messages over UDP transport can have congestion
   implications. Recognizing these deficiencies, the SIMPLE working



Mahy                     Expires August 1, 2004                 [Page 4]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   group developed a protocol to carry sessions of messages called Media
   Sessions Relay Protocol [3] (MSRP). Unfortunately this protocol does
   not include relay support or multiplex multiple threads over a single
   connection, although there is a proposal [25] to add this
   functionality. Core MSRP uses one connection per thread, which does
   not scale for large server to server deployments.  SIP setup of
   instant messaging sessions is not limited to MSRP sessions.  As
   alluded to in the previous section, SIP can setup session of XMPP [4]
   with equal facility as documented here [26].

3. Example: Choosing among multiple clients

   Traditional IM systems generally do a poor job of handling multiple
   simultaneous IM clients online for the same person. While some do a
   better job than many existing systems, handling of multiple clients
   is fairly crude. This becomes a much more significant issue when
   always-on mobile devices are available, but when it is desirable to
   use them only if another IM client is not available.

   Using SIP makes rendezvous decisions explicit, deterministic, and
   very flexible; instead "pager-mode" IM systems use implicit
   implementation-specific decisions which IM clients cannot influence.
   With SIP session mode messaging rendezvous decisions can be under
   control of the client in a predictable, interoperable way for any
   host that implements caller preferences.  As a result, rendezvous
   policy is managed consistently for each address of record.

   The following example shows Juliet with several IM clients where she
   can be reached. Each of these has a unique SIP Contact and XMPP
   resource. The example takes advantage of SIP's capability to "fork"
   an invitation to several Contacts in parallel, in sequence, or in
   combination. Juliet has registered from her chamber, the balcony, her
   PDA, and as a last resort, you can leave a message with her Nurse.
   Juliet's contacts are listed below. The q-values express relative
   preference (q=1.0 is the highest preference).


      We query for a list of Juliet's contacts by sending a REGISTER:

   REGISTER sip:thecapulets.example.com SIP/2.0
   To: Juliet <sip:juliet@thecapulets.example.com>
   From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
   Call-ID: 09887877
   CSeq: 772 REGISTER

      The Response contains her Contacts:

   SIP/2.0 200 OK



Mahy                     Expires August 1, 2004                 [Page 5]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   To: Juliet <sip:juliet@thecapulets.example.com>
   From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
   Call-ID: 09887877
   CSeq: 771 REGISTER
   Contact: <sip:juliet@balcony.thecapulets.example.com>
    ;q=0.9;expires=3600
   Contact: <sip:juliet@chamber.thecapulets.example.com>
    ;q=1.0;expires=3600
   Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600
   Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600


   When Romeo opens his IM program, he selects Juliet and types the
   message "art thou hither?" (instead of "you there?"). His client
   sends a SIP invitation to sip:juliet@thecapulets.example.com.  The
   Proxy there tries first the balcony and the chamber simultaneously. A
   client is running on both those systems, both of which setup early
   sessions of XMPP with Romeo's client.  The client automatically sends
   the message over the XMPP network to the two JIDs involved. After a
   delay of a several seconds with no reply or activity from Juliet, the
   proxy cancels the invitation at her first two contacts, and forwards
   the invitation on to Juliet's PDA. Since her father is talking to her
   about her wedding, she selects "Do Not Disturb" on her PDA, which
   sends a "Busy Here" response. The proxy then tries the Nurse, who
   answers and tells Romeo what is going on.



    Romeo       Juliet's     Juliet/      Juliet/      Juliet/     Nurse
                 Proxy       balcony      chamber       PDA

      |            |            |            |           |           |
      |--INVITE--->|            |            |           |           |
      |            |--INVITE--->|            |           |           |
      |            |<----180----|            |           |           |
      |<----180----|            |            |           |           |
      |---PRACK---------------->|            |           |           |
      |<----200-----------------|            |           |           |
      |<===Early XMPP Session==>| art thou hither?       |           |
      |            |            |            |           |           |
      |            |--INVITE---------------->|           |           |
      |            |<----180-----------------|           |           |
      |<----180----|            |            |           |           |
      |---PRACK----------------------------->|           |           |
      |<----200------------------------------|           |           |
      |<========Early XMPP Session==========>| art thou hither?      |
      |            |            |            |           |           |
      |            |            |            |           |           |



Mahy                     Expires August 1, 2004                 [Page 6]


Internet-Draft            Why Session Mode IM?                  Feb 2004


      |            | .... Time Passes ....   |           |           |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            |--CANCEL--->|            |           |           |
      |            |<---200-----|            |           |           |
      |            |<---487-----|            |           |           |
      |            |----ACK---->|            |           |           |
      |            |--CANCEL---------------->|           |           |
      |            |<---200------------------|           |           |
      |            |<---487------------------|           |           |
      |            |----ACK----------------->|           |           |
      |            |--INVITE---------------------------->|  romeo wants
      |            |            |            |           |  to IM w/ you
      |            |<---486 Busy Here--------------------|           |
      |            |----ACK----------------------------->|           |
      |            |            |            |           |           |
      |            |--INVITE---------------------------------------->|
      |            |<---200 OK---------------------------------------|
      |<--200 OK---|            |            |           |           |
      |---ACK------------------------------------------------------->|
      |<================XMPP Session================================>|
      |            |            |            |           |           |
      |                                         Hi Romeo, Juliet is  |
      |                                         with her father now  |
      |                                         can i take a message?|
      |                                                              |
      |  Tell her to go to confession tommorrow....                  |



4. Manipulating a Session

   Once a conversation is established  using SIP, it is straightforward
   to add, remove, or substitute other media types using a reINVITE or
   UPDATE request. One participant of a conversation can be replaced
   another participant, just like a transfer [5] in a telephone system.
   Likewise it is easy to add or remove additional parties in a
   multi-party conversation (sometimes called a conference [6] in SIP or
   group chat in XMPP).

   An additional non-exhaustive set of participant manipulation features
   such as redirection, queueing, conferences (which can have  sidebars,
   coaching, etc.), live-screening of messages being left, remote
   session monitoring, and remote session control [12] are discussed in
   the SIP call control framework [19].  These features also make it
   very simple to support worker/assistant relationships and groups
   which can barge-in, monitor, and grab each other's sessions with
   proper authorization.  Some of the primitives that enable this



Mahy                     Expires August 1, 2004                 [Page 7]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   functionality are defined in [10], [11], and [9].

   SIP also has a rich mechanism which allows session initiators to
   express their communication preferences [7], such as "I want to talk
   to Rohan's message-taker", "I want to communicate with a live human",
   "I want a mobile device that offers two-way text".  These preferences
   are matched with the capabilities [8] and preferences of the
   receiver.

   Finally SIP provides the opportunity for multiple media types in a
   single session or in related sessions to stays together, if that is
   what is desired.  For example, it is simple in SIP to "transfer" a
   session with IM, audio, and co-browsing from one call center agent to
   another. Similarly groups of cooperating user-agents, for example an
   in-room video conferencing system, a conference phone, an electronic
   whiteboard, and the moderator's laptop can be cooperate such that
   they all can leave or join a related session simultaneously.

5. Direct Client to Client Messaging

   Using the rendezvous features of SIP, but with messaging media going
   directly end-to-end between clients, IM clients could operate more
   autonomously, exchanging messages directly among hosts on the public
   Internet, or in adhoc or link local networks. When available, direct
   mode puts much less strain on the servers and network connections of
   large commercial providers, especially when transporting file or
   attachments. Note that direct mode is not a realistic possibility for
   most IM clients using traditional IM protocols alone--for example
   XMPP-- since most clients use dynamic IP addresses and typically do
   not have access to dynamic DNS. Session mode IM clients would
   frequently still use a SIP Proxy to discover an appropriate contact
   to use, but then the rest of the SIP signaling could be sent directly
   between clients.

   Clients which support both direct mode and server mode could
   determine which to use on a call-by-call basis by using  Interactive
   Connectivity Establishment (ICE) [20].  Clients can also share a
   consistent QoS policy using session mode for networks (such as mobile
   wireless networks) where QoS is needed.

6. Security and Privacy Considerations

   As a rendezvous protocol with diverse uses, SIP can support a number
   of apparently contradictory privacy requirements simultaneously.  For
   example, SIP can support escrowed cross domain anonymity, with the
   possibility for trace and non-repudiation, recording, and legal
   intercept.  This functionality is enabled by SIP features which
   permit third-party assertion of identity [13], and the ability for



Mahy                     Expires August 1, 2004                 [Page 8]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   SIP nodes to loose-route requests through additional intermediaries
   as needed. Applying this capability to sessions of messages allows
   for anonymous, traceable, and optionally recorded sessions and
   conferences with no additional specification work.

   The loose-routing capabilities of SIP also make it very easy to
   introduce brokered federation for and offload of features such as
   spam-prevention and archiving.

   In addition, SIP can provide a one-time symmetric key in offers and
   answers which can be used for bulk message encryption and
   authentication during a session.  This can be accomplished using the
   existing S/MIME symmetric key wrap algorithms.

Normative References

   [1]   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.

   [2]   Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [3]   Campbell, B., "Instant Message Sessions in SIMPLE",
         draft-ietf-simple-message-sessions-00 (work in progress), May
         2003.

   [4]   Miller, J. and P. Saint-Andre, "XMPP Instant Messaging",
         draft-ietf-xmpp-im-12 (work in progress), June 2003.

   [5]   Sparks, R. and A. Johnston, "Session Initiation Protocol Call
         Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
         progress), February 2003.

   [6]   Johnston, A. and O. Levin, "Session Initiation Protocol Call
         Control - Conferencing for User  Agents",
         draft-ietf-sipping-cc-conferencing-00 (work in progress), April
         2003.

   [7]   Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
         Preferences and Callee Capabilities for the Session Initiation
         Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in
         progress), March 2003.

   [8]   Rosenberg, J., "Indicating User Agent Capabilities in the
         Session Initiation Protocol  (SIP)",
         draft-ietf-sip-callee-caps-00 (work in progress), June 2003.



Mahy                     Expires August 1, 2004                 [Page 9]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   [9]   Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
         Event Package for the Session Initiation  Protocol (SIP",
         draft-ietf-sipping-dialog-package-01 (work in progress), March
         2003.

   [10]  Dean, R., Biggs, B. and R. Mahy, "The Session Inititation
         Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03
         (work in progress), March 2003.

   [11]  Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP)
         'Join' Header", draft-ietf-sip-join-01 (work in progress),
         March 2003.

   [12]  Mahy, R., "Remote Call Control in SIP using the REFER method
         and the  session-oriented dialog package",
         draft-mahy-sip-remote-cc-00 (work in progress), October 2003.

   [13]  Peterson, J., "Enhancements for Authenticated Identity
         Management in the Session  Initiation Protocol (SIP)",
         draft-ietf-sip-identity-01 (work in progress), March 2003.

   [14]  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1999.

Informational References

   [15]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
         Instant Messaging", RFC 2778, February 2000.

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

   [17]  Atkins, D. and G. Klyne, "Common Presence and Instant
         Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
         (work in progress), January 2003.

   [18]  Fujimoto, S. and H. Sugano, "Presence Information Data Format
         (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
         2003.

   [19]  Mahy, R., "A Call Control and Multi-party usage framework for
         the Session  Initiation Protocol (SIP)",
         draft-ietf-sipping-cc-framework-02 (work in progress), March
         2003.

   [20]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Nettwork  Address Translator (NAT) Traversal
         for the Session Initiation Protocol (SIP)",



Mahy                     Expires August 1, 2004                [Page 10]


Internet-Draft            Why Session Mode IM?                  Feb 2004


         draft-rosenberg-sipping-ice-00 (work in progress), February
         2003.

   [21]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
         in progress), January 2003.

   [22]  Rosenberg, J., "An Extensible Markup Language (XML) Based
         Format for Watcher  Information",
         draft-ietf-simple-winfo-format-04 (work in progress), January
         2003.

   [23]  Rosenberg, J., "A Watcher Information Event Template-Package
         for the Session Initiation  Protocol (SIP)",
         draft-ietf-simple-winfo-package-05 (work in progress), January
         2003.

   [24]  Miller, J. and P. Saint-Andre, "XMPP Core",
         draft-ietf-xmpp-core-13 (work in progress), June 2003.

   [25]  Jennings, C., Mahy, R. and J. Garg, "SIMPLE Instant Messaging
         Sessions (SIMS)", draft-jennings-simple-sims-00.txt (work in
         progress), Feb 2004.

URIs

   [26]  <http://www.softarmor.com/simple/drafts/morgue/
         draft-sparks-simple-jabber-sessions-00.txt>


Author's Address

   Rohan Mahy
   Cisco Systems, Inc.
   5617 Scotts Valley Drive, Suite 200
   Scotts Valley, CA  95066
   USA

   EMail: rohan@cisco.com












Mahy                     Expires August 1, 2004                [Page 11]


Internet-Draft            Why Session Mode IM?                  Feb 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 assignees.

   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



Mahy                     Expires August 1, 2004                [Page 12]


Internet-Draft            Why Session Mode IM?                  Feb 2004


   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.











































Mahy                     Expires August 1, 2004                [Page 13]


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