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]