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 From: Juliet ;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 From: Juliet ;tag=12345 Call-ID: 09887877 CSeq: 771 REGISTER Contact: ;q=0.9;expires=3600 Contact: ;q=1.0;expires=3600 Contact: ;q=0.4;expires=3600 Contact: ;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] 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]