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]