SIMPLE Group A. Houri Internet-Draft IBM Expires: August 25, 2003 T. Hansen AT&T Laboratories February 24, 2003 SIP/SIMPLE Based Presence and IM Architecture draft-houri-simple-arch-00 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 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. Houri & Hansen Expires August 25, 2003 [Page 1] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 4. High Level Architecture . . . . . . . . . . . . . . . . . 7 4.1 Single Server System . . . . . . . . . . . . . . . . . . . 7 4.2 Multiple Server System . . . . . . . . . . . . . . . . . . 8 5. Specifications . . . . . . . . . . . . . . . . . . . . . . 8 5.1 IMPP/CPIM Specifications . . . . . . . . . . . . . . . . . 9 5.2 SIMPLE Group Specifications . . . . . . . . . . . . . . . 9 5.2.1 Presence . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2 Messaging . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.3 Lists - Events and Manipulation . . . . . . . . . . . . . 11 5.2.4 Publish . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.5 Watchers . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.6 SIMPLE/CPIM Related Docs . . . . . . . . . . . . . . . . . 13 5.2.7 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3 Relevant SIP Group Specifications . . . . . . . . . . . . 14 5.4 Relevant SIPPING Group Specifications . . . . . . . . . . 14 6. Types of Deployments . . . . . . . . . . . . . . . . . . . 15 6.1 Enterprise (Single Domains of Trust) . . . . . . . . . . . 16 6.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 16 6.1.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 16 6.1.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 16 6.1.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 16 6.1.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 16 6.1.4 Advanced Configurations & Scenarios . . . . . . . . . . . 16 6.1.4.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.4.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.4.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Federated Systems . . . . . . . . . . . . . . . . . . . . 17 7.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 17 7.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 17 7.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 17 7.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 18 7.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 18 7.4 Advanced Configurations & Scenarios . . . . . . . . . . . 18 7.4.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 18 7.4.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.4.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Public Systems Interconnecting . . . . . . . . . . . . . . 18 8.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 18 Houri & Hansen Expires August 25, 2003 [Page 2] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 8.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 19 8.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 19 8.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 19 8.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 19 8.4 Advanced Configurations & Scenarios . . . . . . . . . . . 19 8.4.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 19 8.4.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.4.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Open systems . . . . . . . . . . . . . . . . . . . . . . . 20 9.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 20 9.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 20 9.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 20 9.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 20 9.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 20 9.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 20 9.4 Advanced Configurations & Scenarios . . . . . . . . . . . 21 9.4.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Basic User Scenarios . . . . . . . . . . . . . . . . . . . 21 10.1 Locating the Server(s) . . . . . . . . . . . . . . . . . . 21 10.2 Connection . . . . . . . . . . . . . . . . . . . . . . . . 21 10.3 Logging-In (AKA Registering) . . . . . . . . . . . . . . . 21 10.4 Authentication . . . . . . . . . . . . . . . . . . . . . . 22 10.5 Uploading Presence Document . . . . . . . . . . . . . . . 22 10.6 Subscribing to a Presentity . . . . . . . . . . . . . . . 22 10.7 Getting Notifications . . . . . . . . . . . . . . . . . . 22 10.8 Sending IM . . . . . . . . . . . . . . . . . . . . . . . . 22 10.9 Receiving IM . . . . . . . . . . . . . . . . . . . . . . . 22 11. The Presence Document . . . . . . . . . . . . . . . . . . 22 11.1 Composition From Multiple Sources . . . . . . . . . . . . 22 11.2 Status Values . . . . . . . . . . . . . . . . . . . . . . 23 12. Instant Messages . . . . . . . . . . . . . . . . . . . . . 23 13. Advanced Presence Scenarios . . . . . . . . . . . . . . . 23 13.1 Partial Notifications . . . . . . . . . . . . . . . . . . 23 13.2 Authorization of Subscription . . . . . . . . . . . . . . 23 13.3 Presence Lists . . . . . . . . . . . . . . . . . . . . . . 23 13.4 Watchers List . . . . . . . . . . . . . . . . . . . . . . 23 14. Advanced IM Scenarios . . . . . . . . . . . . . . . . . . 23 14.1 IM Sessions . . . . . . . . . . . . . . . . . . . . . . . 24 14.2 IM Conferences . . . . . . . . . . . . . . . . . . . . . . 24 14.2.1 Instant Conferences . . . . . . . . . . . . . . . . . . . 24 14.2.2 Scheduled Conferences . . . . . . . . . . . . . . . . . . 24 14.2.3 Switching between IM Page Mode, IM Sessions and IM Conferences . . . . . . . . . . . . . . . . . . . . . . . 24 15. Client Capabilities . . . . . . . . . . . . . . . . . . . 24 Houri & Hansen Expires August 25, 2003 [Page 3] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 16. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 24 17. Additional Issues and Services . . . . . . . . . . . . . . 25 17.1 Invisible (Lurking) Mode . . . . . . . . . . . . . . . . . 25 17.2 Action Cues . . . . . . . . . . . . . . . . . . . . . . . 25 17.3 Emoticons & Backgrounds . . . . . . . . . . . . . . . . . 25 17.4 Message History . . . . . . . . . . . . . . . . . . . . . 25 17.5 Offline Messages . . . . . . . . . . . . . . . . . . . . . 25 17.5.1 Queued Offline Messages . . . . . . . . . . . . . . . . . 25 17.5.2 Other Offline . . . . . . . . . . . . . . . . . . . . . . 25 17.6 File Sharing . . . . . . . . . . . . . . . . . . . . . . . 25 17.7 Voice . . . . . . . . . . . . . . . . . . . . . . . . . . 26 17.8 Video . . . . . . . . . . . . . . . . . . . . . . . . . . 26 17.9 General Application Invocation . . . . . . . . . . . . . . 26 18. Security Considerations . . . . . . . . . . . . . . . . . 26 Normative References . . . . . . . . . . . . . . . . . . . 26 Non-Normative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 30 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . 31 Houri & Hansen Expires August 25, 2003 [Page 4] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 1. Introduction SIMPLE, SIP and SIPPING groups seems to be the most active groups in the IETF. Currently there are more then a hundred active I-Ds. This document tries to summarize the work in the SIMPLE group by defining what are the possible architectures for the creation of a SIMPLE based presence and IM system. The document starts by a definitions section in which we define the entities and the concepts that will serve us while we describe the architecture. The definitions sections is followed by a high level architecture that defines a very basic presence and IM architecture. The document continues with a specifications section in which we survey the current RFCs and active internet-drafts that will be referred throughout the document. These specifications are actually the building blocks of the systems described. After the introductory sections there are two major parts to this document: The server centric view of the possible systems, in which we describe the possible server deployments of a presence and IM systems. The second major part of the document is the user centric view in which we describe basic and advanced scenarios of presence and IM from the UA's point of view. Note that this is only the very first draft of the document. Most of it is still TBD. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 3. Definitions This document uses terms as defined in various internet-drafts and RFCs. See Section 5 for the complete list and description of specifications used in the document. [TBD. This section will contain a lot of definitions that we will need. Need to specify for each definition, the specification it was taken from, Noting definitions that are defined in this document.] Houri & Hansen Expires August 25, 2003 [Page 5] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. This manipulation can be the side effect of some other action (such as sending a SIP REGISTER request to add a new Contact) or can be done explicitly through the publication of presence documents. We explicitly allow multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and Personal Digital Assistant (PDA)), each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages, or send NOTIFY messages. Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. A presence agent must have knowledge of the presence state of a presentity. This means that it must have access to presence data manipulated by PUAs for the presentity. One way to do this is by co-locating the PA with the proxy/registrar. Another way is to co-locate it with the presence user agent of the presentity. However, these are not the only ways, and this specification makes no recommendations about where the PA function should be located. A PA is always addressable with a SIP URI that uniquely identifies the presentity (i.e, sip:joe@example.com). There can be multiple PAs for a particular presentity, each of which handles some subset of the total subscriptions currently active for the presentity. A PA is also a notifier (defined in RFC 3265 [6]) that supports the presence event package. Presence Server: A presence server is a physical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests. When acting as a PA, it is aware of the presence information of the presentity through some protocol means. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA. Edge Presence Server: An edge presence server is a presence agent that is co-located with a PUA. It is aware of the presence information of the presentity because it is co- located with the entity that manipulates this presence information. Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record Houri & Hansen Expires August 25, 2003 [Page 6] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. 4. High Level Architecture This section describes a very high level of a presence and IM system. The intention of this section is to provide a basis for the description of the more complex system further on. [TBD. Relate between entities and specification documents.] 4.1 Single Server System A system of a single presence server to which user agents are connected will look like the following, +---------+ +----------------+ |Presence | | Authentication | | Server | | Server | +---------+ +----------------+ ^ ^ | | | V | +------------+ | | Registrar/ | | | Locator | | +------------+ | ^ | +---------+ | +---->| Proxy |<-+ +---------+ ^^^^^ ||||| VVVVV User Agents Figure 1 Figure 1 illustrates a very simple (or even simplistic) presence and IM architecture of a single server. Users connect through a proxy to the system. They proxy directs their logon (REGISTER)requests to the registrar that uses a back-end authentication directory for authenticating the users. Subscription and notifications requests are Houri & Hansen Expires August 25, 2003 [Page 7] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 directed to the presence server that serves them. Sending instant messages can be done directly between the users or via the proxy. 4.2 Multiple Server System A system of multiple servers to which user agents are connected will look like the following, +---------+ +---------+ | Single | | Single | | Server | o o o | Server | | System | | System | +---------+ +---------+ ^^^^^ ^^^^^ ||||| ||||| VVVVV VVVVV User Agents User Agents Figure 2 Figure 2 illustrates a more complex scenario where there are multiple units of a single server system. Users may connect to each of the single server systems. Following issues arise: o Mapping of users to their servers - Users may have their presence list and other information stored at one of the servers. When a user logs on, its server side storage has to be retrieved from the appropriate server. Furthermore, changes to the server side storage has to be replicated to the appropriate server o Replication of presence information - When a user logs on to one of the servers and uploads its presence information, other users that are logged on to other servers may subscribe on the user. There should be a way of replicating the presence information between the servers or at least letting other users know where a certain user is logged on. [TBD. How the above problems are solved.] 5. Specifications This section will survey all the active internet drafts and RFCs that are relevant this the SIMPLE based presence and IM architecture. Houri & Hansen Expires August 25, 2003 [Page 8] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 5.1 IMPP/CPIM Specifications The IMPP working group was the first group at the IETF to start working on presence and IM protocols. A protocol was not defined by the IMPP group but very important basic documents were produced. o RFC2778 [2] - The basic IETF document for presence and IM. Defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. o RFC2779 [3] - The second basic IETF document for presence and IM. The document defines the requirements for presence and IM service. The requirements include: Scalability, Format, Security etc. o draft-ietf-impp-cpim-pidf [8] - Specifies the Common Presence and Instant Messaging (CPIM)Presence Information Data Format (PIDF) as a common presence data format for CPIM-compliant Instant Messaging and Presence protocols, and also defines a new media type "application/cpim-pidf+xml" to represent the XML MIME entity for PIDF. o draft-ietf-impp-cpim-msgfmt [9] - Defines the mime type 'Message/ CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. o draft-ietf-impp-pres [10] - One of three related documents [10][11][12]. Defines a common semantics and data formats for presence to facilitate the creation of gateways between presence services. o draft-ietf-impp-im [11] - One of three related documents [10][11][12]. Defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. o draft-ietf-impp-srv [12] - One of three related documents [10][11][12]. Provides guidance for locating the resources associated with URIs that employ the schemes of PRESENTITIES URIs ('pres') as defined in [10] and the INSTANT INBOXES URIs ('im') as defined in [11]. 5.2 SIMPLE Group Specifications The SIMPLE group defines the extensions required for the SIP protocol Houri & Hansen Expires August 25, 2003 [Page 9] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 in order to be able to implement presence and IM system. Following is a list of the active specifications that are group documents or were submitted to the group. Each specification is followed by a short description of what each specification provides. The documents were divided into several categories. 5.2.1 Presence Following documents define the notification mechanisms and requirements for presence notifications using the SIP protocol. o draft-ietf-simple-presence [23] - The basic presence document for SIMPLE. Describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework [6]. o draft-moran-simple-pres-filter-reqs [27] - Defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. o draft-khartabil-simple-presence-filter [24] - Defines a presence filter package. The package provides the mechanism whereby a watcher can specify the presence event filtering rules, using XML, for the presence agent (PA) and how that PA is to behave when receiving such filter. o draft-lonnfors-simple-presinfo-deliv-reqs [25] - Presents requirements for a solution for delivering presence information that aids in reducing and increasing efficiency of devices that have constrains as low data processing capabilities, small display and limited battery power. Other limitations may be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. o draft-lonnofors-simple-partial-notify [26] - Presents a solution for delivering presence information that aids in reducing and increasing efficiency of devices that have constrains as low data processing capabilities, small display and limited battery power. Other limitations may be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. The solution introduces a new MIME-type "partial notifications" and a Require header extension "partial-notification". Houri & Hansen Expires August 25, 2003 [Page 10] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 5.2.2 Messaging Following documents define requirements and ways to implement a session of messages. Note that the MESSAGE method RFC is a SIP group document [7]. o draft-rosenberg-simple-messaging-requirements [21] - Defines a set of requirements for new capabilities for instant messaging and presence in SIP-based systems such as delivery confirmations and is typing indicators. o draft-campbell-simple-im-sessions [20] - The document describes a method of initiating and managing message sessions using SIP. The media session is established using a SIP INVITE, just as a normal audio or video session would be established. o draft-sparks-simple-jabber-sessions [22] - Explores modeling jabber message streams [38] as media sessions, and how they can be initiated with the Session Initiation Protocol. It also explores how these sessions can be integrated into existing session-based multimedia communication applications. 5.2.3 Lists - Events and Manipulation Traditional presence and IM systems usually enable users to store a list of presences on which they subscribe on the server side. The users logging on to the system do not have to send the list every time they logon. Following documents deal with requirements and models for having parallel possibilities in the SIMPLE protocols. o draft-ietf-simple-event-list [17] - Presents an extension to the Session Initiation Protocol (SIP). The extension enables subscribing to a homogeneous collection of event packages. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire collection, and then receive notifications when the state of any of the resources in the collection changes. o draft-ietf-simple-data-req [16] - Provides a framework and requirements for data manipulations for presence. These data manipulations include: presentity list, adding/removing presentities and authorization lists. o draft-isomaki-simple-list-man-sem [18] - Proposes a semantics for SIMPLE list manipulation protocol. No protocol is defined yet. Houri & Hansen Expires August 25, 2003 [Page 11] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 5.2.4 Publish SIMPLE users that need to publish their presence document to the presence server were using two types of workrooms: o Using the REGISTER method for uploading the presence document. o Using other protocols for uploading the presence document Following documents describe how it can be done via the SIP protocol while defining a new PUBLISH method o draft-ietf-simple-publish-reqs [28] - Defines requirements for publishing event state used within the framework for SIP Event Notification (RFC3265 [6]). The first application of this extension is targeted at the publication of presence information. o draft-olson-simple-publish [30] - Describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265 [6]). The first application of this extension is targeted at the publication of presence information. o draft-niemi-simple-publish-framework [29] - Describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework for publication of SIP specific data. This extension derives from the recent Internet Draft defining the PUBLISH method, but instead of using the SIP events framework, it introduces a specific publication framework for the publish mechanism. The main motivations for decoupling publications from events are that the event framework is not overloaded, and the applicability of the PUBLISH method to problem sets similar to those surfacing in the publication of event state is improved. The SIP publication framework is neither intended for general data manipulation, nor is it intended to foster any discussion on the issue of using SIP for everything. 5.2.5 Watchers Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. o draft-ietf-simple-winfo-package [32] - Defines the watcher Houri & Hansen Expires August 25, 2003 [Page 12] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 information template-package for the SIP event framework. This event package is a template-package because it can be applied to any event package, including itself. o draft-ietf-simple-winfo-format [31] - Defines an XML format for watcher information for a resource. 5.2.6 SIMPLE/CPIM Related Docs Following documents define a mapping between the IMPP/CPIM documents (Section 5.1) or define ways to extend what is defined in IMPP/CPIM. o draft-ietf-simple-cpim-mapping [13] - Defines how the SIMPLE work group SIP events package for distribution of presence information [23] and the MESSAGE extension for the transport of instant messages map to the abstract CPIM service [10][11][12], in order to interoperate with other CPIM compliant presence and instant messaging services. o draft-campbell-simple-cpimmsg-sessions [19] - Describes a message session mechanism based on the Common Presence and Instant Messaging message format [9]. o draft-kyzivat-simple-prescaps-reqts [14] - Sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF)[8], as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server. o draft-lonnfors-simple-prescaps-ext [15] - Proposes extensions to Presence Information Data Format (PIDF)[8] to be used within the SIMPLE based presence systems in order to enable building better applications. 5.2.7 Wireless o draft-kiss-simple-presence-wireless-reqs [33] - Defines requirements for Presence Service based on 3GPP specifications and wireless environment characteristics. o draft-niemi-simple-im-wireless-reqs [34] - Lists the requirements specific to 3GPP wireless Instant Messaging systems. Houri & Hansen Expires August 25, 2003 [Page 13] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 5.3 Relevant SIP Group Specifications Following SIP RFCs are very relevant to this document: o RFC3261 [4] - The basic document of Session Initiation Protocol (SIP). o RFC3263 [5] - Describes the DNS procedures used by SIP to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. These procedures also allow a server to send a response to a backup client if the primary client has failed. o RFC3265 [6] - Provides an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The event notification mechanisms defined are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. o RFC3428 [7] - Defines the MESSAGE method as an extension to SIP that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of the SIP protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. 5.4 Relevant SIPPING Group Specifications The SIPPING group is responsible for defining requirements for SIP and SIMPLE work. Following is an initial list of SIPPING documents that are relevant to the architecture described in this document. [TBD. Other relevant SIPPING documents?] o draft-niemi-sipping-event-throttle-reqs [35] - The document defines requirements for all event packages to specify a maximum rate at which event notifications are generated by a single notifier. Such a limit is provided in order to reduce network congestion. In addition to the fixed limits introduced by specific event packages, further mechanisms for limiting the rate of event notification are also allowed to be defined by event package specifications but none have been specified so far. This memo discusses the requirements for a throttle mechanism that allows a subscriber to further limit the rate of event notification. Houri & Hansen Expires August 25, 2003 [Page 14] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 o draft-rosenberg-sipping-conferencing-framework [36] - Defines a framework for how conferencing in SIP can occur. Note that the basic definition of SIP defines dialogs that are two-party by default. The framework in the document describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. o draft-johnston-sipping-cc-conferencing [37] - Defines conferencing call control features for SIP. The document builds on the Conferencing Requirements and Framework documents [36] to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. 6. Types of Deployments Several types of presence and IM systems deployments are described: o Enterprise (Single Domains of Trust)- A presence and IM system that is built for an enterprise use. The employees of the enterprise is usually authenticated using the same credentials that they use for other operations within the enterprise. The system is usually located within the secured enterprise network o Federated Systems - Several networks that have created a federation between them. In these systems a user is able to inter-operate with users on other systems. There is no need for each user of being authenticated since the authentication is done at the level of each system. o Public Systems Interconnecting - A public system that enables registered users to use the services of the system (as AOL, MSN, Yahoo). The users in each public system do not belong to the same organization and therefore can not be trusted as a whole as in enterprise systems. o Open Systems - Users do not belong to an organization and are not registered to use the services of a public system. The services that the users will use will be freely available on the network while peer to peer operations between users will be very common in these system [TBD. Are there other types of deployments?] Houri & Hansen Expires August 25, 2003 [Page 15] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 6.1 Enterprise (Single Domains of Trust) 6.1.1 Definition [TBD. Detailed definition and examples of the system] 6.1.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 6.1.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 6.1.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [5]] 6.1.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 6.1.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 6.1.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 6.1.4 Advanced Configurations & Scenarios Houri & Hansen Expires August 25, 2003 [Page 16] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 6.1.4.1 Firewalls [TBD. Firewall considerations for the system] 6.1.4.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 6.1.4.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 7. Federated Systems 7.1 Definition [TBD. Detailed definition and examples of the system] 7.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 7.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 7.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [5]] 7.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] Houri & Hansen Expires August 25, 2003 [Page 17] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 7.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 7.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 7.4 Advanced Configurations & Scenarios 7.4.1 Firewalls [TBD. Firewall considerations for the system] 7.4.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 7.4.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 8. Public Systems Interconnecting 8.1 Definition [TBD. Detailed definition and examples of the system] 8.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] Houri & Hansen Expires August 25, 2003 [Page 18] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 8.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 8.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [5]] 8.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 8.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 8.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 8.4 Advanced Configurations & Scenarios 8.4.1 Firewalls [TBD. Firewall considerations for the system] 8.4.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] Houri & Hansen Expires August 25, 2003 [Page 19] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 8.4.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 9. Open systems 9.1 Definition [TBD. Detailed definition and examples of the system] 9.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 9.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 9.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [5]] 9.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 9.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 9.3.4 State Replication [TBD. What state the servers in the system should replicate. How Houri & Hansen Expires August 25, 2003 [Page 20] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 it can be done.] 9.4 Advanced Configurations & Scenarios 9.4.1 Firewalls [TBD. Firewall considerations for the system] 9.4.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 9.4.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 10. Basic User Scenarios [TBD. The very basic user scenarios that will be done by a UA that uses presence and IM] 10.1 Locating the Server(s) [TBD. How the server(s) that the user will use will be located. Mostly referring to RFC 3263 [5]] 10.2 Connection [TBD. Who creates the connection to whom. Reusing of existing connections. Re-establishing broken connections etc.] 10.3 Logging-In (AKA Registering) [TBD. Use of the REGISTER method in order to logon into the domain.] Houri & Hansen Expires August 25, 2003 [Page 21] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 10.4 Authentication [TBD. What authentication methods can be used in order to authenticate a used in the domain.] 10.5 Uploading Presence Document [TBD. Use of PUBLISH for uploading the presence document. In systems that do not support PUBLISH yet what other methods are available for publishing the presence document (REGISTER fields, HTTP, Web Services)] 10.6 Subscribing to a Presentity [TBD. Simple subscription to a single presentity] 10.7 Getting Notifications [TBD. Getting notifications on the subscribed presentity. Assuming no authorization or other issues.] 10.8 Sending IM [TBD. Sending IM to another user.] 10.9 Receiving IM [TBD. Receiving IM from another user] 11. The Presence Document [TBD. The definition of a presence document. Mostly referring to the pidf doc [8].] 11.1 Composition From Multiple Sources [TBD. Composing a presence document when there are multiple publishers] Houri & Hansen Expires August 25, 2003 [Page 22] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 11.2 Status Values [TBD. Capture the latest on the ongoing discussion on status values] 12. Instant Messages [TBD. On the possible format and content of IMs] 13. Advanced Presence Scenarios [TBD. Covering advanced scenarios of usage of presence and notifications] 13.1 Partial Notifications [TBD. Summarizing the latest work on partial notifications of changes to presence documents] 13.2 Authorization of Subscription [TBD. Scenarios of how subscription authorization can be done. The topic should include privacy lists (who can see me) and authorization by an action of the user being subscribed on] 13.3 Presence Lists [TBD. Catching the latest on events list] 13.4 Watchers List [TBD. Describing what is watchers. How to subscribe to your watchers etc.] 14. Advanced IM Scenarios [TBD. Advanced scenarios of IMs including sessions conferences etc.] Houri & Hansen Expires August 25, 2003 [Page 23] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 14.1 IM Sessions [TBD. The famous subject of creation of IM session. Describe the various proposals in this ares. Describe the additional components that systems will have to implement in order to enable IM sessions. Describe the possible scenarios for creating IM sessions] 14.2 IM Conferences [TBD. Describe the various possibilities of creation a conference of IM. Use the relevant parts (for IM) from the conference model work] 14.2.1 Instant Conferences [TBD. An instant conference is a conference that is created on the spot. Usually it is the evolution of one on one IM session. See Section 14.2.3] 14.2.2 Scheduled Conferences [TBD. A scheduled conference is a conference in which invitations are sent to people and advance and they join the conference on the specified time.] 14.2.3 Switching between IM Page Mode, IM Sessions and IM Conferences [TBD. Hoe switching can be done between various types of IM interactions. Not sure if there is already work regarding this subject] 15. Client Capabilities [TBD. How a client informs the server and other clients on its capabilities. It is a big issue especially on mobile devices] 16. Profiles [TBD. Yet another big issue, Searching for other users, Sending profiles to other users etc.] Houri & Hansen Expires August 25, 2003 [Page 24] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 17. Additional Issues and Services 17.1 Invisible (Lurking) Mode [TBD. I want to login into a system see other people while they do not see me. Should it be allowed? Should users in the system be notified that lurking is possible.] 17.2 Action Cues [TBD. How action cues are going to be sent between users. for example and indication that your IM partner is typing a response now] 17.3 Emoticons & Backgrounds [TBD. How the emoticons/backgrounds are downloaded to the client?] [How is the content of the emoticons/backgrounds is controlled?] 17.4 Message History [TBD. Storing of message history. Retrieving message history. Who can store? Who can retrieve? Should I be able to block other users that I chat with from saving my messages? etc.] 17.5 Offline Messages [TBD. Getting messages that were sent to me while my client is not connected to the system. Two ways are discussed below] 17.5.1 Queued Offline Messages [TBD. Messages that are delivered to the user when s/he logs in] 17.5.2 Other Offline [TBD. Delivery via email, SMS etc.] 17.6 File Sharing [TBD. Sending files between users. A lot of security and bandwidth Houri & Hansen Expires August 25, 2003 [Page 25] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 issues should be raised here] 17.7 Voice [TBD. Using client capacities, presence information and IMs in order to start a voice session. The voice session itself will be done via the INVITE message. We might talk here about sending voice as the payload of IMs.] 17.8 Video [TBD. Using client capacities, presence information and IMs in order to start a video session. The video session itself will be done via the INVITE message. We might talk here about sending video as the payload of IMs.] 17.9 General Application Invocation [TBD. General application invocation using the mechanisms discussed in this document. I.e. client capabilities, presence information and IMs] 18. Security Considerations This document introduces no known security considerations. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [4] 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. [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Houri & Hansen Expires August 25, 2003 [Page 26] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [8] Fujimoto, S. and H. Sugano, "Common Presence and Instant Messaging (CPIM)Presence Information Data Format", draft-ietf-impp-cpim-pidf-07 (work in progress), January 2003. [9] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [10] Crocker, D. and J. Peterson, "Common Profile: Presence", draft-ietf-impp-pres-01 (work in progress), December 2002. [11] Crocker, D. and J. Peterson, "Common Profile: Instant Messaging", draft-ietf-impp-im-01 (work in progress), December 2002. [12] Crocker, D. and J. Peterson, "Address Resolution for Instant Messaging and Presence", draft-ietf-impp-srv-01 (work in progress), December 2002. [13] Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE Presence and Instant Messaging", draft-ietf-simple-cpim-mapping-01 (work in progress), June 2002. [14] Kyzivat, P., "Requirements for SIP Capabilities in PIDF", draft-kyzivat-simple-prescaps-reqts-00 (work in progress), October 2002. [15] Kiss, K. and M. Lonnfors, "SIMPLE PIDF presence capabilities extension", draft-lonnfors-simple-prescaps-ext-00 (work in progress), October 2002. [16] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in SIMPLE Systems", draft-ietf-simple-data-req-00 (work in progress), October 2002. [17] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Collections", draft-ietf-simple-event-list-00 (work in progress), February 2003. [18] Isomaki, M., "Semantic Description of SIMPLE List Manipulation Houri & Hansen Expires August 25, 2003 [Page 27] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 Operations", draft-isomaki-simple-list-man-sem-00 (work in progress), November 2002. [19] Campbell, B., "Instant Message Transport Sessions using the CPIM Message Format", draft-campbell-simple-cpimmsg-sessions-00 (work in progress), October 2002. [20] Rosenberg, J. and B. Campbell, "Instant Message Sessions in SIMPLE", draft-campbell-simple-im-sessions-00 (work in progress), October 2002. [21] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-00 (work in progress), December 2002. [22] Sparks, R., "Establishing jabber Messaging Sessions with the Session Initiation Protocol", draft-sparks-simple-jabber-sessions-00 (work in progress), October 2002. [23] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [24] Khartabil, H., "Event Notification Filtering for Presence", draft-khartabil-simple-presence-filter-00 (work in progress), January 2003. [25] Costa-Requena, J., "Requirements for Efficient Delivery of Presence Information", draft-lonnfors-simple-presinfo-deliv-reqs-00 (work in progress), January 2003. [26] Costa-Requena, J. and E. Leppanen, "Partial Notification of Presence Information", draft-lonnofors-simple-partial-notify-00 (work in progress), January 2003. [27] Moran, T. and S. Addagatla, "Requirements for Presence specific Event Notification Filters", draft-moran-simple-pres-filter-reqs-00 (work in progress), January 2003. [28] Campbell, B., "SIMPLE Presence Publication Requirements", draft-ietf-simple-publish-reqs-00 (work in progress), February 2003. [29] Niemi, A., "SIP Specific Data Publication Framework", Houri & Hansen Expires August 25, 2003 [Page 28] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 draft-niemi-simple-publish-framework-00 (work in progress), September 2002. [30] Campbell, B., "SIMPLE Presence Publication Mechanism", draft-olson-simple-publish-01 (work in progress), October 2002. [31] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", draft-ietf-simple-winfo-format-04 (work in progress), January 2003. [32] 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. [33] Kiss, K. and G. Bajko, "Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics", draft-kiss-simple-presence-wireless-reqs-01 (work in progress), October 2002. [34] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-00 (work in progress), October 2002. [35] Niemi, A., "Requirements for Limiting the Rate of Event Notifications", draft-niemi-sipping-event-throttle-reqs-00 (work in progress), January 2003. [36] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing-framework-01 (work in progress), February 2003. [37] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-johnston-sipping-cc-conferencing-01 (work in progress), February 2003. Non-Normative References [38] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging", draft-ietf-xmpp-im-02 (work in progress), February 2003. Houri & Hansen Expires August 25, 2003 [Page 29] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 Authors' Addresses Avshalom Houri IBM Science Park Building 18/D Rehovot Israel Phone: +972 8 9409761 Ext. 123 EMail: avshalom@il.ibm.com Tony Hansen AT&T Laboratories Middletown, NJ 07748 USA Phone: +1.732.420.8934 EMail: tony@att.com Appendix A. Acknowledgements The authors gratefully acknowledges the contributions of: Jonathan Rosenberg, Robert Sparks, Jon Peterson, and, Ben Campbell. Houri & Hansen Expires August 25, 2003 [Page 30] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 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 (2003). 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 Houri & Hansen Expires August 25, 2003 [Page 31] Internet-Draft SIP/SIMPLE Based Presence and IM Architecture February 2003 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. Houri & Hansen Expires August 25, 2003 [Page 32]