Internet Engineering Task Force SIMPLE WG
Internet Draft J.Rosenberg
dynamicsoft
draft-rosenberg-simple-components-00.txt
February 22, 2002
Expires: August 2002
A Component Model for SIMPLE
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The SIMPLE working group has developed a core set of specifications
for messaging and presence functionality. However, those protocols
alone are not sufficient to build a complete IM and presence
application. In this document, we advocate a componentized model,
whereby the other pieces of the system are very loosely coupled, and
easily swapped out for others, in order to allow innovation and
differentiation. We also propose some simple solutions for several of
them to allow for interop.
J.Rosenberg [Page 1]
Internet Draft simple-component February 22, 2002
1 Introduction
The SIMPLE working group has nearly completed it specification of a
core set of protocols for presence [1] and Instant Messaging [2]. The
group has also nearly completed a set of protocols in support of end
user authorization. These protocols define an additional event
package called watcher info [3] [4], which allows a user to know when
someone has subscribed to them.
It is obvious that these protocols alone are insufficient to build a
complete IM and presence application. In this document, we advocate a
componentized architecture for building a complete application. In
that architecture, the system is broken up into groups of loosely
related components, any of which can be swapped out for alternative
solutions. This allows for differentiation amongst providers and for
future proofing. We identify the main pieces of a presence and IM
application as they are envisioned today, and overview some of the
potential solutions for them. In some areas, we propose additional
protocol specification.
2 The Component Architecture Philosophy
One of the main engineering goals of the SIP, SIMPLE and SIPPING
working groups has been to specify modular protocols that could be
use to build a wide variety of applications by plugging the protocols
together in different ways. This design philosophy has manifested
itself in many ways.
One example is the application component architecture for SIP [5].
This architecture advocates building complex, media-intensive
applications through an interaction between a centralized application
server and a set of application unaware components. These components,
such as dialog servers, conference servers, and text-to-speech
servers, are controlled by the application server using general
purpose tools, primarily SIP, HTTP and VoiceXML. The benefit of this
architecture is that it allows for reuse of components across
applications, rapid development (as a result of the component reuse),
and easy development of differing applications on the same platform.
Another example is the SIP events framework [6]. Rather than build
specific asynchronous notification protocols for each use, a general
framework was built. This framework allows for the definition of
packages, which fill in the details specific to a particular usage.
This allows for a wide variety of problems to be solved using the
same tool, rather than inventing a new one for each new problem.
Another example is the REFER method [7]. This method is a general
purpose mechanism that allows one user to ask another to send a
J.Rosenberg [Page 2]
Internet Draft simple-component February 22, 2002
request. This tool has found application to call transfer [8] and
third party call control [9], amongst others.
The SIP for presence specification is another example. It represents
a general purpose mechanism that allows one entity to subscribe to
the presence of another, and receive notifications of it. This
mechanism can be used for consumer presence and IM buddy list
applications, but it can also be used for other applications. As an
example, the subscribe can be an application server, which subscribes
to a user presence in order to trigger a phone call when the user
logs on.
3 Requirements of a Presence and IM Application
The SIMPLE specifications provide the core presence and IMn
functionality needed in any "buddy list" style consumer presence and
IM application. In such an application, a user has one or more lists
of buddies representing users whose presence they would like to see.
Those lists are displayed to the user. As the presence status of
those users change, the display changes in some way to reflect it.
Users can select a user from the list, and send them an IM. These
applications also typically support group chats, where a user can
start an IM chat, and invite users to it as desired.
These applications are frequently quite feature rich. The following
is a list of common features found in such applications:
Buddy List Subscription:
The user can select from a number of lists that define
their buddies, and subscribe to those lists as a whole,
rather than subscribing to each user individually.
Buddy List Management:
The user needs to be able to create groups of buddies, add
users to that list, remove users from the list, and look at
the content of a list of buddies.
Block and Allow Lists:
The user can define block lists and allow lists. These
define sets of users you can (or cannot) subscribe and/or
send an instant message to that user. There is wide
variability in the set of policies. Some systems allow for
users to specify details about what aspects of presence
state are revealed to which subscribers. Other systems
allow for time-of-day based message screening. Other
J.Rosenberg [Page 3]
Internet Draft simple-component February 22, 2002
systems allow a user to set their presence status to "do-
not-disturb" which will block all incoming IM until the
status changes. In additiona, many systems support an
"invisible" mode, where a user appears offline, but instant
messages are still delivered.
Threaded View:
Instant messages with a user or group of users are viewed
in a threaded fashion, with past messages from all users
showed above new messages. This provides context for the
conversation.
is-Typing:
When two users are sending instant messages to each other,
when one user starts typing a new message, the other sees
some kind of an indication that the other is typing. This
helps to avoid the frequent "glare" that arises when both
users send each other messages at the same time, which can
make the conversation flow more complicated.
Setting Status:
Users can explicitly set their presence status.
Real time Authorization:
When user A subscribes to user B, if user B is online, user
B will receive a notification of this request. User B can,
at that time, accept or reject the subscription.
File Sharing:
Many applications also allow for file sharing. In this
application, the sender chooses a menu item to send a file
to a user. They supply the identity of the user and the
file. The recipient gets an IM indicating that a file has
been sent. The recipient can choose to download the file,
or reject the transfer. The key aspect of this feature is
the indirection; the file is not pushed, but rather, pulled
by the recipient.
Voice:
Many applications allow a user to start a voice or video
conversation, in addition to, or instead of, an IM session.
J.Rosenberg [Page 4]
Internet Draft simple-component February 22, 2002
IM Delivery Confirmation:
In some systems, especially SMS, delivery of messages can
take some time. As a result, delivery confirmation is
supported. This confirmation allows a user to get notified
when a message is actually delivered to the end user.
Group IM:
Many systems support group IM. In a typical usage, a user
creates a group. They can then add users to the group.
Users in the group can all send an IM, which is received by
all other participants in the group. Users are notified
when a new participant joins the group, or when a
participant leaves the group. Some systems allow a user to
join a group without being explicitly invited. Some systems
allow for long-lived groups which are topical in nature,
more along the lines of traditional IRC.
Offline Messages:
When a user is "offline", for some definition of offline
(for PC systems, this usually means not logged in. For
mobile applications, it means that the user cannot be
reached for some reason) their messages are stored in the
network. When the user connects at a later time, they are
able to see the messages sent to them while offline.
Message Histories:
Many IM systems allow a user to view their message history.
This history represents the set of messages sent from or to
the user. Most systems store these histories in the
network, and some store it locally. In either case, users
can search their message histories, delete older messages,
and so on.
User and Group Profiles:
Some systems allow users to specify profiles for themselves
- this includes hobbies and personal interests, for
example. These systems also support search capabilities, so
that a user can find all people that like chess. Other
systems allow for profiles to be associated with groups, so
that a user can search for all groups talking about chess.
4 Analyzing the Requirements
J.Rosenberg [Page 5]
Internet Draft simple-component February 22, 2002
Looking at the features, we observe that there are certain related
groups of features.
4.1 User Data Manipulation
Management of the buddy list, management of block and allow lists,
management of message histories, and manipulation of user and group
profiles are all similar problems. These are operations that are
client to server, and involve manipulation of persistent data used by
the servers in the network. The operations are also frequently
performed by users, rather than automata. The manipulations are
performed by a user to the servers run by their own provider, as
opposed to inter-domain. The manipulations are not real time in
nature. They typically involve users viewing the data, and based on
what they see, perform some kind of change. Another commonality is
that these are also areas where there can, and should, be substantial
variation amongst providers on feature sets. For example, the set of
authorization mechanisms (allow and block lists) is rich with
variability.
As a result, one way to handle these is through web browsing. Users
can simply view web pages that present HTML or WML interfaces to
manage these lists and define policies. Use of a dynamically rendered
UI provides the opportunity for substantial vendor differentiation,
without any required standards work. This means interoperability
without loss of flexibility, a truly useful goal.
Another way to handle these is through a voice interface, controlled
by VoiceXML, for example. This is similar to the web approach in
terms of its flexibility and interoperability. However, a voice
interface is probably less usable than a web or WAP interface.
Another mechanism is through database manipulation. Since all of
these feature involve manipulation and viewing of data, it can be
done through database update protocols, such as LDAP. Of course,
interoperability would require agreement on a common schema.
Agreement on a schema is difficult, since it will limit the feature
sets and is not easily changeable.
There appears to be pressure from the industry to have a standards
based mechanism for these interfaces that can be driven by an
automata, instead of a user. It is our recommendation that this be
done based on SOAP. A simple WSDL can be developed for a baseline
feature set, which all providers would implement. Providers could
also choose to define, and publish (if they choose) WSDL for more
enhanced capabilities. This would allow for interoperability, but
still permit provider differentiation and flexibility. SOAP seems an
appropriate tool for this problem. Another advantage of SOAP is that
J.Rosenberg [Page 6]
Internet Draft simple-component February 22, 2002
there are several techniques available for compression (WBXML, WAP,
TCP compression) that can improve performance for wireless, without
making the protocols wireless specific.
It would be our proposal for the IETF SIMPLE group to generate a
specification that contains a set of baseline WSDL for these
functions.
4.2 Notification Features
Several of the other features fit into the category of notification
services. These include confirmation of IM delivery, the is-typing
indicator, notification of offline messages, notification of changes
in the buddy lists, and notifications of changes in group
participation for group chats.
Clearly, the right solution is to define sip-events packages for any
of these functions for which one does not already exist. However, we
observe that there are already sip-events packages under development
that can be used to help solve these problems. Subscription to a
buddy list is described in [10], and it directly addresses that
problem. The is-typing indicator is a form of notification of user
input, and is therefore within the scope of the SIP event package for
keys group participation is directly covered by the event package for
conferences [11]. Of course, that mechanism is for conferences in
general, and is not specific to IM. The same mechanism would
therefore support IM, voice, video or any other type of conference.
Notifications for offline messages are the subject of the SIP event
package for message waiting indicators [12].
The only missing piece is an event package for confirmation of
message delivery. This would be very similar to the way notification
works for REFER [7]. The MESSAGE request would contain an Event
header, creating an implicit subscription for delivery. When the
message is delivered, a NOTIFY is sent based on that subscription.
Given the existence of the REFER mechanism, which is almost an
identical problem, it is fairly easy to develop this specification.
Indeed, it could find applicability to delivery of any kind of
request, not just MESSAGE.
It is therefore our proposal to move forward with the three existing
event packages within sipping, and begin work on a new package for
confirmation of message delivery.
4.3 Group Features
The ability to facilitate group communications is a strength of SIP.
When IM is done using the session model [13], all of the work that
J.Rosenberg [Page 7]
Internet Draft simple-component February 22, 2002
has been done on conferencing in SIP is directly applicable to IM.
Techniques for creation of conferences, inviting users to
conferences, and joining an existing conference, for example, have
already been worked out [14]. Learning of the identities of
conference participants, and notification of joins and leaves from
conferences are all handled by the SIP conference package [11].
Another aspect of groups is conference policy - controlling you can
or cannot speak, who can or cannot participate, and so on. Work on
conference control has started and stopped many times in the history
of IETF. In most cases, it was simply not necessary - people didn't
really use it. In other cases where it was found to be useful, it was
done through a web or WAP interface, and therefore required no
standardization. It is not clear that this has changed.
As a result, our recommendation is to continue to move forward with
the existing conferencing work within SIPPING, and to rapidly move
forward with the IM session model within SIMPLE.
4.4 File Sharing
The file sharing feature combines two very different functions. The
first function is the ability to send an instant message that
contains content referenced through a URI. That capability is
inherent in MESSAGE as a result of the text/uri-list MIME type, as
described in [15] for web page sharing.
The far more complicated aspect is how the user determines the URI to
include in the instant message. In some cases, the user may already
have a URI, in which case there is no problem. In other cases, the
content may be on the end system. Since we do not anticipate most
users will be able to run web servers, the content will need to be
pushed into some kind of "content repository" that is present in the
network. Such a repository would provide an interface that would
allow a user to request storage. The repository would respond with a
URI that the user can use. The user pushes the content to the URI
(using an HTTP PUT, supposedly), and then can send the instant
message using the URI. The receiver then fetches the content with an
HTTP GET.
The missing piece of the puzzle, from a standards perspective, is a
standardized interface to the repository. This is a complex problem,
with many security and legal implications (it is effectively another
form of file sharing ala Napster and Gnutella). It is not clear that
the IETF can or should tackle the standardization of such an
interface. From a technology perspective, SOAP also appears the right
thing, as this is clearly a "web service" which has far broader
application than just IM.
J.Rosenberg [Page 8]
Internet Draft simple-component February 22, 2002
4.5 Threading
Threading allows a bunch of instant messages to be tied together in a
logical way, so that the user interface can present them in a
coherent manner. In the session model, threading is inherent; all of
the messages within a session constitute a thread. In the paging
model, however, there is no clear threading capability. Several
drafts have been written that propose a new header for this purpose
[16] [17]. However, it is our contention that this capability is
already inherent in SIP through the In-Reply-To header. In the paging
model, the Call-ID provides a unique identifier for each IM. An IM
sent in response to one received previously fits the definition
associated with In-Reply-To. As such, we would propose that all IM in
a thread simply carry the Call-ID of the original message in the
thread within the In-Reply-To header.
4.6 Presence Publication
Presence publication (also known as setting status) has also achieved
a great deal of attention within the IETF. A requirements draft has
been written [18] and proposals have been made for an implementation
[19]. The problem is very similar to the other data manipulation
features described in Section 4.1, except that an automata will
frequently be the client. As such, we still contend that a SOAP
mechanism may be appropriate.
However, it is fundamental to the model of presence that the
components of a presence document can come from many different
sources, using many different protocols. Mandating a single mechanism
for this interface is a mistake.
4.7 Real Time Authorization
Real time authorization is provided through the watcher information
package [3], along with the data manipulation functions of Section
4.1. A user subscribes to their own watcher information. When someone
subscribes to their presence, they receive a watcher information
notification. They can then go and provide an authorization decision
for that user, if desired. This has the advantage of providing a
single interface for setting authorization policy, whether it be the
result of some stimulus (a user subscribed to you) or just an
asynchronous decision that is made.
5 Conclusion
It is fundamental to the SIP architecture that the protocols do not
specify applications or services. Rather, they provide tools upon
which applications can be built. This is true for the simple
J.Rosenberg [Page 9]
Internet Draft simple-component February 22, 2002
specifications, which provide a core messaging, subscription and
notification service upon which many applications can be built. A
consumer oriented "buddy list and IM" application requires more than
just subscription and IM. The right way to provide those is to
assemble additional components that can provide the features needed.
By piecing the application together from a set of modular components,
providers obtain future-proofing, flexibility, and a means for
differentiation.
It has become clear from several trends that the IETF needs to insure
that all of the components needed to build a commercial buddy list
application are available. Most of those components are already
finished or under development within IETF. For those that are not, we
propose that they be rapidly progressed. Our specific plan of action
is this:
1. The SIMPLE group adopts draft-rosenberg-simple-buddylist-
package [10] as a work item.
2. The SIPPING group adopts draft-culpepper-sip-key-events as
a starting point towards a work item, and make sure that
the is-typing function is addressed.
3. The SIPPING group adopts draft-rosenberg-sip-call-package
[11] as a work item.
4. The SIPPING group adopts draft-mahy-sipping-message-waiting
[12] as a work item.
5. The SIPPING group develops an event package for message
confirmation, almost identical to the one used in REFER
[7]. Indeed, that exact package may be directly applicable.
6. The SIMPLE group formally adds draft-ietf-simple-im-session
[13] and draft-ietf-simple-im-sdp [20] as charter items,
and completes them.
7. The SIMPLE group defines and completes an IM transport
protocol for the session model.
8. The SIPPING group completes draft-ietf-sipping-
conferencing-models [14].
9. The SIMPLE group develops and publishes an RFC defining
SOAP WSDL for basic buddy list manipulation, block and
allow list manipulation, and presence document publication.
This would provide all the pieces needed for building a wide variety
J.Rosenberg [Page 10]
Internet Draft simple-component February 22, 2002
of presence and IM driven applications, whether they be a consumer
buddy list application, a presence-enabled conferencing application,
an application that holds phone calls while you are typing an IM
(important for phones which allow you to either use a data
application, or be on the phone, but not both), and so on.
6 Author's Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
7 Bibliography
[1] J. Rosenberg, "SIP extensions for presence," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Work in progress.
[2] J. Rosenberg et al. , "SIP extensions for instant messaging,"
Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in
progress.
[3] J. Rosenberg, "A SIP event sub-package for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[4] J. Rosenberg, "An XML based format for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[5] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
server component architecture for SIP," Internet Draft, Internet
Engineering Task Force, Mar. 2001. Work in progress.
[6] A. Roach et al. , "SIP-specific event notification," Internet
Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.
[7] R. Sparks, "The refer method," Internet Draft, Internet
Engineering Task Force, Oct. 2001. Work in progress.
[8] R. Sparks, "SIP call control - transfer," Internet Draft,
Internet Engineering Task Force, July 2001. Work in progress.
J.Rosenberg [Page 11]
Internet Draft simple-component February 22, 2002
[9] M. Bhatia, "3pcc using the REFER method," Internet Draft,
Internet Engineering Task Force, Oct. 2001. Work in progress.
[10] J. Rosenberg and B. Campbell, "A SIP event package for buddylist
presence," Internet Draft, Internet Engineering Task Force, Nov.
2001. Work in progress.
[11] J. Rosenberg and H. Schulzrinne, "SIP event packages for call
leg and conference state," Internet Draft, Internet Engineering Task
Force, July 2001. Work in progress.
[12] R. Mahy and I. Slain, "SIP event package for message waiting
indication," Internet Draft, Internet Engineering Task Force, Nov.
2001. Work in progress.
[13] B. Campbell and J. Rosenberg, "SIP instant message sessions,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[14] J. Rosenberg and H. Schulzrinne, "Models for multi party
conferencing in SIP," Internet Draft, Internet Engineering Task
Force, Nov. 2001. Work in progress.
[15] X. Wu and H. Schulzrinne, "Use SIP MESSAGE method for shared web
browsing," Internet Draft, Internet Engineering Task Force, Nov.
2001. Work in progress.
[16] P. Koskelainen and H. Schulzrinne, "Group messaging in SIP,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[17] P. Koskelainen, "MTP extensions for message threading and
message identification," Internet Draft, Internet Engineering Task
Force, Jan. 2002. Work in progress.
[18] S. Donovan, "Requirements for publication of SIP related service
data," Internet Draft, Internet Engineering Task Force, Nov. 2001.
Work in progress.
[19] B. Stucker, "SIP-specific network service publishing," Internet
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.
[20] B. Campbell and J. Rosenberg, "SDP extensions for SIP instant
message sessions," Internet Draft, Internet Engineering Task Force,
July 2001. Work in progress.
J.Rosenberg [Page 12]
Internet Draft simple-component February 22, 2002
Full Copyright Statement
Copyright (c) The Internet Society (2002). 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 assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
J.Rosenberg [Page 13]
Table of Contents
1 Introduction ........................................ 2
2 The Component Architecture Philosophy ............... 2
3 Requirements of a Presence and IM Application ....... 3
4 Analyzing the Requirements .......................... 5
4.1 User Data Manipulation .............................. 6
4.2 Notification Features ............................... 7
4.3 Group Features ...................................... 7
4.4 File Sharing ........................................ 8
4.5 Threading ........................................... 9
4.6 Presence Publication ................................ 9
4.7 Real Time Authorization ............................. 9
5 Conclusion .......................................... 9
6 Author's Addresses .................................. 11
7 Bibliography ........................................ 11
J.Rosenberg [Page 1]