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 From: Juliet ;tag=12345 Call-ID: 09887877 CSeq: 772 REGISTER The Response contains her Contacts: SIP/2.0 200 OK 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---------------->| | | | 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] 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]