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]