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

Versions: 00 01 02

SIMPLE WG                                                        R. Mahy
Internet-Draft                                                 Airespace
Expires: August 2, 2005                                         Feb 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Mahy                     Expires August 2, 2005                 [Page 1]


Internet-Draft            Why Session Mode IM?                  Feb 2005


   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.

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  . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   7.2   Informational References . . . . . . . . . . . . . . . . . . 10
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12
































Mahy                     Expires August 2, 2005                 [Page 2]


Internet-Draft            Why Session Mode IM?                  Feb 2005


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 2, 2005                 [Page 3]


Internet-Draft            Why Session Mode IM?                  Feb 2005


   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 2, 2005                 [Page 4]


Internet-Draft            Why Session Mode IM?                  Feb 2005


   group developed a protocol to carry sessions of messages called Media
   Sessions Relay Protocol [3] (MSRP), and a companion relay extension
   [15].  SIP setup of instant messaging sessions is not limited to MSRP
   sessions.  As alluded to in the previous section, SIP can setup
   sessions 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).




















Mahy                     Expires August 2, 2005                 [Page 5]


Internet-Draft            Why Session Mode IM?                  Feb 2005


      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
   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---------------->|            |           |           |



Mahy                     Expires August 2, 2005                 [Page 6]


Internet-Draft            Why Session Mode IM?                  Feb 2005


      |<----200-----------------|            |           |           |
      |<===Early XMPP Session==>| art thou hither?       |           |
      |            |            |            |           |           |
      |            |--INVITE---------------->|           |           |
      |            |<----180-----------------|           |           |
      |<----180----|            |            |           |           |
      |---PRACK----------------------------->|           |           |
      |<----200------------------------------|           |           |
      |<========Early XMPP Session==========>| art thou hither?      |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            | .... 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



Mahy                     Expires August 2, 2005                 [Page 7]


Internet-Draft            Why Session Mode IM?                  Feb 2005


   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 [20].  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
   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.  In fact, peer-to-peer mode is one of the primary
   benefits of MSRP in a mobile wireless environment.  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



Mahy                     Expires August 2, 2005                 [Page 8]


Internet-Draft            Why Session Mode IM?                  Feb 2005


   Connectivity Establishment (ICE) [21].  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
   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.

7.  References

7.1  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., "The Message Session Relay Protocol",
         draft-ietf-simple-message-sessions-09 (work in progress),
         October 2004.

   [4]   Saint-Andre, P., Ed., "Extensible Messaging and Presence
         Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
         October 2004.

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



Mahy                     Expires August 2, 2005                 [Page 9]


Internet-Draft            Why Session Mode IM?                  Feb 2005


         progress), October 2004.

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

   [7]   Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
         Preferences for the Session Initiation Protocol (SIP)", RFC
         3841, August 2004.

   [8]   Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
         Agent Capabilities in the Session Initiation Protocol (SIP)",
         RFC 3840, August 2004.

   [9]   Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
         the Session Initiation  Protocol (SIP)",
         draft-ietf-sipping-dialog-package-05 (work in progress),
         November 2004.

   [10]  Mahy, R., Biggs, B. and R. Dean, "The Session Initiation
         Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.

   [11]  Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
         "Join" Header", RFC 3911, October 2004.

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

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

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

   [15]  Jennings, C. and R. Mahy, "Relay Extensions for Message
         Sessions Relay Protocol (MSRP)",
         draft-ietf-simple-msrp-relays-02 (work in progress), October
         2004.

7.2  Informational References

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

   [17]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant



Mahy                     Expires August 2, 2005                [Page 10]


Internet-Draft            Why Session Mode IM?                  Feb 2005


         Messaging / Presence Protocol Requirements", RFC 2779, February
         2000.

   [18]  Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
         (CPIM): Message Format", RFC 3862, August 2004.

   [19]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
         J. Peterson, "Presence Information Data Format (PIDF)", RFC
         3863, August 2004.

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

   [21]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Multimedia Session Establishment Protocols",
         draft-ietf-mmusic-ice-03 (work in progress), October 2004.

   [22]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

   [23]  Rosenberg, J., "An Extensible Markup Language (XML) Based
         Format for Watcher Information", RFC 3858, August 2004.

   [24]  Rosenberg, J., "A Watcher Information Event Template-Package
         for the Session Initiation Protocol (SIP)", RFC 3857, August
         2004.

   [25]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
         Protocol (XMPP): Core", RFC 3920, October 2004.

URIs

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


Author's Address

   Rohan Mahy
   Airespace
   110 Nortech Pkwy
   San Jose, CA  95134
   USA

   EMail: rohan@ekabal.com



Mahy                     Expires August 2, 2005                [Page 11]


Internet-Draft            Why Session Mode IM?                  Feb 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mahy                     Expires August 2, 2005                [Page 12]


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