SIMPLE Group A. Houri Internet-Draft IBM Expires: December 28, 2003 T. Hiller Lucent T. Hansen AT&T Laboratories June 29, 2003 SIP/SIMPLE Based Presence and IM Architecture draft-houri-simple-arch-01 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 December 28, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document is a initial attempt in creating a document that will describe the architecture of a presence and instant messaging system. The 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, functional model, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this Houri, et al. Expires December 28, 2003 [Page 1] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 document and understand how the IETF protocols can be used for building a complete system and how it should work. The main changes from the previous version of the document is that sections about functional model and basic call flows were added. 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 . . . . . . . . . . . . . . . 10 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. Basic Functional Model . . . . . . . . . . . . . . . . . . 15 7. Basic Flows . . . . . . . . . . . . . . . . . . . . . . . 19 7.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 20 7.2 Sending and Receiving Messages . . . . . . . . . . . . . . 22 7.2.1 Sending a Pager Mode Message . . . . . . . . . . . . . . . 22 7.2.2 Receiving a Pager Mode Message . . . . . . . . . . . . . . 26 7.2.3 Deferred Message Delivery to IM Application . . . . . . . 29 7.2.4 Delivery of Deferred Message to User . . . . . . . . . . . 32 7.2.5 Logging Pager-Mode Messages . . . . . . . . . . . . . . . 34 7.2.6 Establishing a Point-to-Point Messaging Session . . . . . 34 7.2.7 Sending a Message Within a Messaging Session . . . . . . . 37 7.2.8 Receiving a Message Within a Messaging Session . . . . . . 39 7.2.9 Adding a Member to an Established Session . . . . . . . . 39 7.2.10 Transitioning a Two Party Session to a Multiparty Conference and Adding a Third Participant . . . . . . . . 40 7.2.11 Adding a User to a Multiparty Session . . . . . . . . . . 44 7.2.12 Leaving a Messaging Session . . . . . . . . . . . . . . . 45 7.2.13 Logging Messaging Session Messages . . . . . . . . . . . . 45 7.3 Group Operations . . . . . . . . . . . . . . . . . . . . . 45 7.3.1 Creating a Group . . . . . . . . . . . . . . . . . . . . . 46 7.3.2 Deleting a Group . . . . . . . . . . . . . . . . . . . . . 48 7.3.3 Modifying_a_Group . . . . . . . . . . . . . . . . . . . . 49 7.3.4 Retrieving_a_Group . . . . . . . . . . . . . . . . . . . . 50 Houri, et al. Expires December 28, 2003 [Page 2] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.3.5 Publishing User Management Policy . . . . . . . . . . . . 51 7.4 Access Deferred Messages . . . . . . . . . . . . . . . . . 52 7.5 Presence Operations . . . . . . . . . . . . . . . . . . . 53 7.5.1 Publishing Presence . . . . . . . . . . . . . . . . . . . 54 7.5.2 Subscribing to Presence (or a Presence List) . . . . . . . 55 7.5.3 Receiving a Presence Notification . . . . . . . . . . . . 57 7.5.4 Querying Presence . . . . . . . . . . . . . . . . . . . . 58 8. Access Points and Barriers . . . . . . . . . . . . . . . . 58 8.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 59 8.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 59 8.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. Deployments . . . . . . . . . . . . . . . . . . . . . . . 59 9.1 Enterprise (Single Domains of Trust) . . . . . . . . . . . 60 9.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 60 9.1.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 60 9.1.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 60 9.1.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 60 9.1.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 60 9.1.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 60 9.1.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 60 9.2 Federated Systems . . . . . . . . . . . . . . . . . . . . 61 9.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 61 9.2.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 61 9.2.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 61 9.2.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 61 9.2.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 61 9.2.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 61 9.2.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 61 9.3 Public Systems Interconnecting . . . . . . . . . . . . . . 61 9.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 62 9.3.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 62 9.3.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 62 9.3.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 62 9.3.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 62 9.3.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 62 9.3.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 62 9.4 Open systems . . . . . . . . . . . . . . . . . . . . . . . 62 9.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 62 9.4.2 Components & Diagrams . . . . . . . . . . . . . . . . . . 63 9.4.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 63 9.4.3.1 Locating Other Servers . . . . . . . . . . . . . . . . . . 63 9.4.3.2 Creating Connections . . . . . . . . . . . . . . . . . . . 63 9.4.3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 63 9.4.3.4 State Replication . . . . . . . . . . . . . . . . . . . . 63 10. Basic User Scenarios . . . . . . . . . . . . . . . . . . . 63 10.1 Locating the Server(s) . . . . . . . . . . . . . . . . . . 63 10.2 Connection . . . . . . . . . . . . . . . . . . . . . . . . 64 10.3 Logging-In (AKA Registering) . . . . . . . . . . . . . . . 64 Houri, et al. Expires December 28, 2003 [Page 3] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 10.4 Authentication . . . . . . . . . . . . . . . . . . . . . . 64 10.5 Uploading Presence Document . . . . . . . . . . . . . . . 64 10.6 Subscribing to a Presentity . . . . . . . . . . . . . . . 64 10.7 Getting Notifications . . . . . . . . . . . . . . . . . . 64 10.8 Sending IM . . . . . . . . . . . . . . . . . . . . . . . . 64 10.9 Receiving IM . . . . . . . . . . . . . . . . . . . . . . . 64 11. The Presence Document . . . . . . . . . . . . . . . . . . 65 11.1 Composition From Multiple Sources . . . . . . . . . . . . 65 11.2 Status Values . . . . . . . . . . . . . . . . . . . . . . 65 12. Instant Messages . . . . . . . . . . . . . . . . . . . . . 65 13. Advanced Presence Scenarios . . . . . . . . . . . . . . . 65 13.1 Partial Notifications . . . . . . . . . . . . . . . . . . 65 13.2 Authorization of Subscription . . . . . . . . . . . . . . 65 13.3 Presence Lists . . . . . . . . . . . . . . . . . . . . . . 65 13.4 Watchers List . . . . . . . . . . . . . . . . . . . . . . 66 14. Advanced IM Scenarios . . . . . . . . . . . . . . . . . . 66 14.1 IM Sessions . . . . . . . . . . . . . . . . . . . . . . . 66 14.2 IM Conferences . . . . . . . . . . . . . . . . . . . . . . 66 14.2.1 Instant Conferences . . . . . . . . . . . . . . . . . . . 66 14.2.2 Scheduled Conferences . . . . . . . . . . . . . . . . . . 66 14.2.3 Switching between IM Page Mode, IM Sessions and IM Conferences . . . . . . . . . . . . . . . . . . . . . . . 66 15. Client Capabilities . . . . . . . . . . . . . . . . . . . 67 16. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 67 17. Additional Issues and Services . . . . . . . . . . . . . . 67 17.1 Invisible (Lurking) Mode . . . . . . . . . . . . . . . . . 67 17.2 Action Cues . . . . . . . . . . . . . . . . . . . . . . . 67 17.3 Emoticons & Backgrounds . . . . . . . . . . . . . . . . . 67 17.4 Message History . . . . . . . . . . . . . . . . . . . . . 67 17.4.1 Offline Messages . . . . . . . . . . . . . . . . . . . . . 67 17.4.2 Queued Offline Messages . . . . . . . . . . . . . . . . . 68 17.4.3 Other Offline . . . . . . . . . . . . . . . . . . . . . . 68 17.5 File Sharing . . . . . . . . . . . . . . . . . . . . . . . 68 17.6 Voice . . . . . . . . . . . . . . . . . . . . . . . . . . 68 17.7 Video . . . . . . . . . . . . . . . . . . . . . . . . . . 68 17.8 General Application Invocation . . . . . . . . . . . . . . 68 18. Security Considerations . . . . . . . . . . . . . . . . . 68 18.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 69 18.2 Network Authentication of the endpoint . . . . . . . . . . 69 18.3 Endpoint Authentication of the Service Elements . . . . . 69 18.4 Authorization for Service . . . . . . . . . . . . . . . . 70 18.5 Integrity and Privacy of SIP/SIMPLE Messages . . . . . . . 70 18.6 Configuration of Subscriber Data or Stored Messages . . . 70 Normative References . . . . . . . . . . . . . . . . . . . 71 Non-Normative References . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 74 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 75 Intellectual Property and Copyright Statements . . . . . . 76 Houri, et al. Expires December 28, 2003 [Page 4] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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, et al. Expires December 28, 2003 [Page 5] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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 [8]) 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, et al. Expires December 28, 2003 [Page 6] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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, et al. Expires December 28, 2003 [Page 7] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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, et al. Expires December 28, 2003 [Page 8] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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. [TBD. Update and re-arrange the references.] o RFC2778 [3] - 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 [4] - 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 [10] - 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 [11] - 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 [12] - One of three related documents [12][13][14]. Defines a common semantics and data formats for presence to facilitate the creation of gateways between presence services. o draft-ietf-impp-im [13] - One of three related documents [12][13][14]. Defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. o draft-ietf-impp-srv [14] - One of three related documents [12][13][14]. Provides guidance for locating the resources associated with URIs that employ the schemes of PRESENTITIES URIs ('pres') as defined in [12] and the INSTANT INBOXES URIs ('im') as defined in [13]. Houri, et al. Expires December 28, 2003 [Page 9] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.2 SIMPLE Group Specifications The SIMPLE group defines the extensions required for the SIP protocol 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 [25] - 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 [8]. o draft-moran-simple-pres-filter-reqs [29] - 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 [26] - 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 [27] - 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 [28] - 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 Houri, et al. Expires December 28, 2003 [Page 10] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 "partial-notification". 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 [9]. o draft-rosenberg-simple-messaging-requirements [23] - 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 [22] - 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 [24] - Explores modeling jabber message streams [40] 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 [19] - 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 [18] - 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 [20] - Proposes a semantics for Houri, et al. Expires December 28, 2003 [Page 11] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 SIMPLE list manipulation protocol. No protocol is defined yet. 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 [30] - Defines requirements for publishing event state used within the framework for SIP Event Notification (RFC3265 [8]). The first application of this extension is targeted at the publication of presence information. o draft-olson-simple-publish [32] - 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 [8]). The first application of this extension is targeted at the publication of presence information. o draft-niemi-simple-publish-framework [31] - 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, Houri, et al. Expires December 28, 2003 [Page 12] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 and therefore learn about changes to it. o draft-ietf-simple-winfo-package [34] - Defines the watcher 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 [33] - 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 [15] - Defines how the SIMPLE work group SIP events package for distribution of presence information [25] and the MESSAGE extension for the transport of instant messages map to the abstract CPIM service [12][13][14], in order to interoperate with other CPIM compliant presence and instant messaging services. o draft-campbell-simple-cpimmsg-sessions [21] - Describes a message session mechanism based on the Common Presence and Instant Messaging message format [11]. o draft-kyzivat-simple-prescaps-reqts [16] - Sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF)[10], 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 [17] - Proposes extensions to Presence Information Data Format (PIDF)[10] 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 [35] - Defines requirements for Presence Service based on 3GPP specifications and wireless environment characteristics. o draft-niemi-simple-im-wireless-reqs [36] - Lists the requirements specific to 3GPP wireless Instant Messaging systems. Houri, et al. Expires December 28, 2003 [Page 13] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.3 Relevant SIP Group Specifications Following SIP RFCs are very relevant to this document: o RFC3261 [6] - The basic document of Session Initiation Protocol (SIP). o RFC3263 [7] - 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 [8] - 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 [9] - 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 [37] - 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, et al. Expires December 28, 2003 [Page 14] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 o draft-rosenberg-sipping-conferencing-framework [38] - 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 [39] - Defines conferencing call control features for SIP. The document builds on the Conferencing Requirements and Framework documents [38] 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. Basic Functional Model Figure 3 shows a generic presence and IM system, including SIP/SIMPLE flows. The various deployment types above are specializations of the generic model. Figure 1 shows the general SIP/SIMPLE architcture. All flows are SIP/SIMPLE (author note - the network presence sources is incorrectly drawn in the figure and needs to be fixed). Houri, et al. Expires December 28, 2003 [Page 15] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 +-----------+ |Network | +-----------+ |Presence | | AAA | |Sources | | | +----+------+ +-----+-----+ | | +------+ +------------+--------------------------+ | | | | | | | | +-----------+ +---+--+----+ +-----+-----+ +-------+ +-----+-----+ |Messaging | |Presence | |Conference +---+Message+--+IM | |Gateway | |Application| |Server | |Store | |Application| +-----------+ +----|------+ +-------+---+ +-------+ +-----+-----+ | | | | | | | | | +--------------+ | +-------------------+ +---------------------------+ | | | | | | | +-----------+ +-+-+-+----+-+ | End User | |Home Serving| | | |Proxy | +------+----+ +---+--+----++ | | | | | | | | | +----------------+ | +-------------+ | | | | +------+--+--+ +--------+-------+ +----+----+ | Edge | |Service Provider| |Transport| | Proxy | |Edge Proxy | |Proxy | +------------+ +----------------+ +---------+ Figure 3 Houri, et al. Expires December 28, 2003 [Page 16] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure 4 shows the functional architecture for group managment. +-----------+ | AAA | | | +-----+-----+ | +----------------+-----------------+ | | | | | | +-----+-----+ +-----+-----+ +-----+-----+ |Presence | |Conference | |IM | |Application| |Server | |Application| +----+------+ +----+------+ +-----+-----+ | | | | | | +--------------+ | +---------------+ | | | | | | +-----------+ +---+-+--+---+ | End User |----------|Group Mgt | | | |Directory | +-----------+ +------------+ Figure 4 Houri, et al. Expires December 28, 2003 [Page 17] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 The following figure shows the functional architecture for users accessing deferred messages. +-----------+ | AAA | | | +-----+-----+ | | | | +-----+-----+ | Message | | Store | +-----+-----+ | | | | +-----+-----+ | End User | | | +-----------+ Figure 5 The elements of the sytem are in the above figures are: o End point: nodes that support the SIP/SIMPLE presence and IM. o Home Serving Proxy (HSP): a server that supports registrar, proxy, and application interface functions. o Transport Proxy: a SIP/SIMPLE node that provides transport of messages but is not directly servicing the actual requests of the SIP/SIMPLE protocol. The proxy may route SIP/SIMPLE messages to the HSP to/from the end point, or to/from other HSPs. o Edge Proxy: a specialized proxy that many architectures use as an intermediary between the end point and the fixed network, often provides (SIP/SIMPLE) compression, authentication, and admission Houri, et al. Expires December 28, 2003 [Page 18] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 control function. o Service Provider Edge Proxy: a specialized proxy used as an intermediary from the home service provider to other service providers or external systems. o Network Presence Sources: Source of presence information not published directly by user equipment. Examples might include adapters for HLR registration state, geo-location systems, and the like. o AAA: Performs authentication, authorization, and accounting functions on behalf of the Radio Network and IP Access and SIP entities. Only one monolithic AAA server is depicted; but it may be that proxy AAA servers are involved to proxy AAA to an AAA server that can authenticate the user, i.e., AAA Proxies are not shown in the figures. Furthermore, the AAA server that authenticates the user is not necessarily the AAA server that authorizes various services. (???what does that mean in a real system???) o Messaging Conference Server: Provides messaging sessions by duplicating messages received from one end point to all the endpoints of a conference session. o Message Store: Provides persistent storage of messages when users are not available (e.g., the user is in a tunnel) or when messages must be archived. o Instant Messaging Application: Supports the delivery of pager mode messages to the message store for users that are not currently available; may also archive messages for later retrieval. o Presence Application: Supports presence subscription, notification, and publication. o Group Management Directory: Stores the lists of users associated with groups. o Gateway: will note be specified in this document because the gateway interacts with systems not named nor specified herein. 7. Basic Flows Houri, et al. Expires December 28, 2003 [Page 19] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.1 Registration This section states requirements for a registration function that associates an address of record with an IP address that has been assigned to a user endpoint. An example of an address of record is one of the legal formats of a URI [RFC 2396]. The following example assumes that the user has gained access to an access network and has been assigned an IP address. The user must perform SIP registration to associate the assigned IP address with their address of record. This registration also indicates to the network the instant message capabilities that are supported by the end point. Figure 6 shows the message exchange. The HSP utilizes HAAA of the end point to authenticate and authorize the user to register. After completion of registration, the home server stores the end point's address and is able to send messages to the endpoint. The registration does not authorize any service nor does it indicate to end point the services supported by the server. Refer to Section 10.4 for a discussion on registration authentication. Houri, et al. Expires December 28, 2003 [Page 20] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Registration EP HSP AAA Watcher | | | | | (1) Register | | | | Request | | | |---------------->| | | | | | | | | (2) AAA | | | | Request | | | |-------------->| | | | | | | | (3) AAA | | | | Response | | | |<--------------| | | | | | | (4) Register | | | | Response | | | |<----------------| Registrar | | | | Stores Contact| | | | Address | | | |--------+ | | | | | | | | | | | | | |<-------+ | | | | | | | | | | | | Send | | | | registration | | | | messages to | | | | watcher | | | |------------------------------>| | | | | Figure 6 1. The end point sends a Registration Request to the HSP. 2. The HSP sends an AAA Request to the HAAA server. 3. The HAAA server sends an AAA Response to the HAAA server. 4. The HSP acknowledges the Registration Request to the end point with a Register Response. 5. The HSP stores the new contact in its registration database. 6. if there are any registration watchers, the HSP issues Houri, et al. Expires December 28, 2003 [Page 21] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 registration event notifications to them. 7.2 Sending and Receiving Messages Instant messaging shall support two different messaging modes: Pager mode: Each message is self-contained in one instant messaging request message. This mode is most useful for short sequences of messages, for small messages, and for messages sent to few users or to a static group of users. (See RFC 3228 [5]) for more information.) Session mode. A set of messages is carried via some transport protocol; this protocol is not SIP. The function of SIP in this case is to establish a messaging session between the interested parties. The choice of the transport protocol to support a messaging session is congestion controlable protocol as TCP/SCTP. This mode is most useful for extended sequences of messages and for large messages. The session mode can be externded to iclude chat room like sessions where messages are sent to a largenumber of users, or to a group of users that may change over the life of the message. For short messages, especially in a wireless environment, pager mode is more spectrally efficient and represents lower latency to the user that establishing separate transport sessions. This transport session is independent of any transport involved in the transport of SIP/SIMPLE control messages. If the user plans on sending many messages, or large messages, pager-mode is less efficient in comparison to session mode. It is possible that a message contains a reference (e.g., a URL) that points to a large message instead of containing the message itself. This section first addresses pager mode and then session mode messaging. 7.2.1 Sending a Pager Mode Message The end point sends a pager-mode request to the sender Home Service Proxy (HSP). This may occur via intermediary SIP proxies if necessary. The pager mode request contains the logical name of the desired target user or group. The body of the pager-mode request contains a message encapsulated in the form of a valid MIME format, which includes text, general multi media such as audio, still photos, or video. MIME is the widely used format for email attachments. The sender HSP receives the pager-mode request and queries the user's Houri, et al. Expires December 28, 2003 [Page 22] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 HAAA to verify that the user is allowed to send a message through this proxy. The authorization response from the HAAA includes transmission policy logic for the user. The authorization can be cached and details are left to ???what???, i.e., it is not necessary for the HSP to check the AAA for the user for each pager mode request. Authentication and Authorization mechanisms are discussed in Section 10.4. The sender HSP then executes user transmission policy logic e.g., expands the logical name of the target to which the message is being sent, expands nicknames to logical names, etc. The HSP sends the request to the sender IM Application, which verifies the user is authorized for service; if so logs the message on behalf of the user. As in the case of the HSP, the authorization can be cached and details are left to ???what???. In the typical case, the sender HSP then determines if the pager mode request is targeted to a user in the domain of the sender HSP. If this is the case, the HSP sends the request to the target user's IM Application. That IM Application logs the pager mode request and proxies it to the sender HSP, which then delivers the requst to the target user. The receiver endpoint responds with an acknowledge response to the sender HSP, which proxies the response to the sender endpoint. If the message is not targeted to a user in the sender HSP domain, the sender HSP then proxies the request onward via intermediary SIP proxies towards the destination. The message is delivered to the receiver's HSP, which proxies the pager mode message to the IM Application that supports the target user, as explained in Section 7.2.2. The receiver's HSP responds with an acknowledge response to the sender HSP, which proxies it to the sending user. Figure 7 shows a message exchange associated assuming a sender HSP up to the point of delivery to the receiver HSP. Figure 8 then completes the scenario. If some intermediary proxy in the chain at any point is unable to forward the message, that proxy returns an appropriate error response. It is possible that the endpoint could be able to determine the receiver HSP without using the sending HSP; however, this would bypass the sender IM Application. Houri, et al. Expires December 28, 2003 [Page 23] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End Sender IM HAAA Receiver Point HSP Application HSP | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) AAA | | | | | Request | | | | |------------>| | | | | | | | | | (6) AAA | | | | | Response | | | | |<------------| | | | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager- | | | | | Mode Request| | | | |--------------------------------------->| | | | | | | | | | | | |(9) Pager- | | | | |Mode Response| | | | |<---------------------------------------- | | | | | | (10) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 7 Houri, et al. Expires December 28, 2003 [Page 24] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 1. The endpoint station sends a pager mode request. 2. The sender HSP authenticates the user's request by sending an AAA request to the user's HAAA. 3. The HAAA authenticates and authorizes the user and sends an AAA response to the sender HSP. 4. The sender HSP proxies the request to the sender IM Application. 5. The IM Application authenticates and authorizes the user's request by sending an AAA request to the user's HAAA. 6. The HAAA authenticates and authorizes the user and sends an AAA response to the IM Application. 7. The sender IM Application archives the message and proxies the request back to the sender HSP. 8. The sender HSP proxies the request to the receiver HSP. 9. The receiver's HSP proxies a request response to the sender HSP. 10. The sender HSP sends a request response to the sending endpoint. If the user plans on sending messages to a group, the user or some other party must have previously created the desired group. A group is created using list management as described below (see Section 7.3.1. In this case the pager-mode request is sent to the HSP serving the group. The list's logical name is the target name of the pager mode request. There are two alternative approaches outlined herein for the delivery of the pager mode request to a group: o The HSP serving the list sends the pager mode request to all the recipients per the list; recipients then acknowledge the pager mode request and one acknowledge is received per received recipient. It is possible the members of the lists are additional groups themselves. for the case of wireless use, a sending endpoint (mobile station) receives one acknowledge from all physical recipients, which may be a spectral burden if the final expansion of the list is very large. o The HSP serving the list verifies it can expand the list, sends one acknowledge to the entity that sent the pager mode request, which can be another HSP or the endpoint, and creates a new pager mode request to each of the recipients on the list. The sending endpoint only receives one acknowledge, which is spectrally more efficient. Houri, et al. Expires December 28, 2003 [Page 25] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Security associated with sending a pager mode request is discussed in the section [TBD] 7.2.2 Receiving a Pager Mode Message The above scenario shows a user sending a pager-mode request to a receiver's HSP. This section shows the reception process for the page-mode from the point of reception by the receiver's HSP. If the pager-mode request was sent to many receivers, they will all behave with the reception process below. A message targeted to the user's address of record is delivered to that user's HSP (the receiver HSP). The receiver HSP recognizes that the address of record is served by this HSP, i.e., is in the administrative domain of this HSP. The receiver HSP verifies that the receiving user is authorized to receive message through this HSP by sending an AAA request to the HAAA of the targeted user. The HAAA of the target user authorizes the receiver's HSP to deliver the message in an AAA Response and provides a reception policy to the receiver's HSP. The authorization can be cached and details are tbd, i.e., it is not necessary for the HSP to check the AAA for the user for each pager mode request. Authentication and Authorization is discussed in Section 10.4. The receiver's HSP then executes routing or filtering logic associated with this user (user policy), and acts accordingly, e.g., discards the message, stores it for later delivery, etc. In the typical case the user is authorized and willing to receive the message and has previously registered a contact address. The receiver HSP then proxies the pager-mode request to the receiver's IP application, which verifies the user is authorized for service, and proxies an acknowledge back. As in the case of the HSP, the authorization can be cached and details tbd. The receiver HSP then consults its registration table for that logical name, and then finds the IP address of the endpoint. The receiver HSP then sends the request to the associated IP address. The message is received at the endpoint and the endpoint responds with an acknowledge response, which is routed via proxies to the entity that sent the pager-mode request. From the previous section we see that that entity could be the endpoint itself that is the origin of the pager-mode request, or other sender HSPs that expanded the target list. (editor note: would the response have to pass via the sender HSP?) Lastly, the receiving endpoint alerts its user upon reception of the pager-mode request. See Figure 8 for scenario example. Because wireless resources are scarce and the user may not desire messages from just anyone, the user may populate a policy in the HSP that controls how incoming messages will be processed. For example, Houri, et al. Expires December 28, 2003 [Page 26] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 "unwanted" messages may be discarded, allowing the user to avoid charges associated with such messages. (See section [TBD]) Houri, et al. Expires December 28, 2003 [Page 27] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Sender Receiver IM HAAA End HSP HSP Application Point | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) AAA | | | | | Request | | | | |------------>| | | | | | | | | | (6) AAA | | | | | Response | | | | |<------------| | | | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager- | | | | | Mode Request| | | | |--------------------------------------->| | | | | | | | | | | | |(9) Pager- | | | | |Mode Response| | | | |<---------------------------------------| | | | | | | (10) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 8 Houri, et al. Expires December 28, 2003 [Page 28] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 1. The sender HSP sends a pager mode request to the receiver HSP. 2. The receiver HSP veifies that the user is authorized to recieve such requests by sending an AAA request to the HAAA of the target user. 3. The HAAA authenticates and authorizes the user and sends an AAA response to the receiver HSP. 4. The receiver HSP proxies the request to the receiver IM Application. 5. The IM Application authenticates and authorizes the user's request by sending an AAA request to the user's HAAA. 6. The user's HAAA authenticates and authorizes the user and sends an AAA response to the IM Application. 7. The receiver IM Application archives the message and proxies the request back to the receiver HSP. 8. The HAAA sends an AAA response to the receiver HSP that authorizes the pager-mode request and that may contain a reception policy for the target user. 9. After possibly screening the request based on some policy, the receiver HSP sends the request to the endpoint. 10. The endpoint sends a request response to the receiver HSP. 11. The receiver HSP sends the request response to the sender HSP. 7.2.3 Deferred Message Delivery to IM Application It may be in Figure 8 that the receiver endpoint is not avaible. In this case, the receiver IM Application will archive the message at the message store and arrange for delivery later. When the receiver HSP receives the pager mode request from the sender HSP, it then sends the pager-mode request to the receiver IM Application. Pager-mode messages are delivered to the recipient's IM application, which applies local policy in determining what to do with that message. In the typical case, the policy will be to forward the message to the registered contact if there is one, and to store the message for future delivery if there is no registered contact. Another reasonable policy might be to reject the message if there are no registered contacts for the recipient. If the message is stored Houri, et al. Expires December 28, 2003 [Page 29] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 for deferred delivery, the IM application may (based on policy) indicate in its response to the sender that delivery of the message has been deferred. Th The IM Application also logs the message. The following call flow shows the delivery of a pager-mode message to an IM application, and the storing of that message by the IM application for deferred delivery to the intended recipient. The actual delivery of the message to the user will occur at some future time, and is addressed in a separate call flow in the following section. Houri, et al. Expires December 28, 2003 [Page 30] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Sender Receiver IM HAAA Message HSP HSP Application Store | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) Store | | | | | Message | | | | |------------------------->| | | | | | | | | | | | | |(6) Acknowledge | | | |<-------------------------| | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 9 1. The sender HSP sends a pager mode request to the receiver HSP. 2. The receiver HSP verifies that the user is authorized to receive such requests by sending an AAA request to the HAAA of the target user. 3. The receiver HSP proxies the request to the receiver IM Application. 4. The receiver IM Application archives the message in the message Houri, et al. Expires December 28, 2003 [Page 31] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 store. 5. The message store acknowledges successful storage to the IM Application. 6. The IM Application sends a request response to the receiver HSP. 7. The receiver HSP sends a request response to the sender HSP. 7.2.4 Delivery of Deferred Message to User In the previous section, the IM Application archived the message in the message store. At a later point in time, the user becomes available to receive instant messages. The IM application learns the user is available when it receives a presence notification that indicates the user is available to receive deferred instant messages. Houri, et al. Expires December 28, 2003 [Page 32] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Presence Receiver IM HAAA Message Application HSP Application Store | | | | | | (1) available| | | | | notification | | | | |------------->| | | | | |(2) available| | | | |notification | | | | |------------>| | | | | | | | | | | | | | | | | | | | | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) Store | | | | | Message | | | | |------------------------->| | | | | | | | | | | | | |(6) Acknowledge | | | |<-------------------------| | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 10 1. The IM Application sends a message retrieve request to the message store. 2. The message store responds with deferred messages. 3. The IM Application sends one pager-mode request to the receiver HSP for each message returned by the message store. 4. The receiver HSP sends a pager-mode request to the MS. Houri, et al. Expires December 28, 2003 [Page 33] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5. The MS sends a pager-mode response back to the receiver HSP. 6. The receiver HSP sends a pager-mode response back to the IM Application 7.2.5 Logging Pager-Mode Messages Logging pager-mode messages is outside the scope of this document. 7.2.6 Establishing a Point-to-Point Messaging Session There are two options for session based message transport: o Direct connections between parties; for two users this can be point-to-point, otherwise multicast is assumed. o Connections via a network based conference-like function that duplicates messages. The endpoint sends a messaging session request to its Home Service Proxy (HSP). This messaging session invitation does not actuate the transport session establishment itself; rather it serves to invite desired entities to establish the transport protocol instance that will intrinsically support message transport. The messaging session request indicates a messaging session of some type, e.g., CPIM/TCP, XMPP, etc., that is desired. The request contains the logical name of the desired target user or group as well as information describing the message transport session to be established. The HSP receives this messaging session request and sends an authentication request to the HAAA of the user to verify that the user is authorized to such a request through this proxy. The HAAA responds with an AAA response, which contains a transmission policy. The HSP then executes user transmission policy logic, e.g., expands the logical name, expands nicknames associated with the logical name, etc. In the typical case, the HSP determines if the transport establish request is targeted to a user in the domain of the HSP. If so the HSP delivers the messaging session request to the target user. If the messaging session request is not targeted to a user in the domain of the HSP, the HSP then proxies the request onward towards the receiver HSP of the target user via intermediary proxies. If some proxy in the chain is unable to forward the messaging session request, that proxy returns an appropriate error response. Otherwise, the request is delivered to the receiver HSP, which then sends an AAA to the target user's HAAA to request authorization for the messaging session request. The HAAA responds with an AAA Houri, et al. Expires December 28, 2003 [Page 34] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 response. The receiver HSP proxies the messaging session request to the target user. The endpoint alerts the user so it can determine whether to accept the messaging session request or not. If the target user accepts the request, it sends a messaging session response to its HSP, which proxies the messaging session response via the intermediary proxies to the sender's HSP. At this point, the endpoint and the terminating entity execute the desired transport protocol establish that was identified by the messaging session request. Houri, et al. Expires December 28, 2003 [Page 35] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure 11 provides an example flow of a point-to-point messaging session establishment. End Sender Receiver Sender Receiver End Point HSP HSP HAAA HAAA Point | | | | | | |(1) messaging | | | | |session | | | | | |request | | | | | | | (2) AAA | | | | | | Request | | | | | |------------------------->| | | | | | | | | | | | | | | | | (3) AAA | | | | | | Response | | | | | |<-------------------------| | | | | | | | | | |(4) messaging| | | | | |session | | | | | |request | | | | | |------------>| (5) AAA | | | | | | Request | | | | | |----------------------->| | | | | | | | | | | (6) AAA | | | | | | Response | | | | | |<-----------------------| | | | |(7) messaging | | | | |session | | | | | |request | | | | | |---------------------------------->| | | |(8) messaging | | | | |session | | | | | |response | | | | | |<----------------------------------| | | | | | | | |(9) messaging| | | | | |session | | | | | |response | | | | | |<------------| | | | |(10) messaging | | | | |session | | | | | |response | | | | | |<-----------| | | | | | | | | | | Houri, et al. Expires December 28, 2003 [Page 36] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure 11 1. The endpoint sends a messaging session invitation to the senders HSP. 2. The sender HSP authenticates the user's request and verifies the user is authorized to use that HSP. The sender HSP sends the request to the receiver HSP. 3. The receiver HSP sends the request to the receiver. 4. The receiver sends a message session response to the receiver HSP. 5. The receiver HSP sends a message session response to the sender HSP. 6. The sender HSP sends a message session response to the endpoint. 7. The endpoint sends a message session acknowledge to the target. 8. The two endpoints establish a messaging session. 7.2.7 Sending a Message Within a Messaging Session When the messaging session as establishment is complete, the user may send messages using it. This is shown in Figure 12. If a network based conference server is involved, it will copy the messages and forward them via the transport connection. Houri, et al. Expires December 28, 2003 [Page 37] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 | | | | | (1) Messaging Session | | Establishment Complete | |<------------------------>| | | | | | | | | | (2) Message over | | Messaging Session | |<------------------------>| | | | | | | Figure 12 1. The messaging session is established, which may be between two users or between each user and the conference server. 2. The message is sent over the messaging session. Houri, et al. Expires December 28, 2003 [Page 38] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.2.8 Receiving a Message Within a Messaging Session When the transport session as negotiated by SIP is complete, a user may receive messages via the transport session as shown below. | | | | | (1) Messaging Session | | Establishment Complete | |<------------------------>| | | | | | | | | | (2) Message over | | Messaging Session | |<------------------------>| | | | | | | Figure 13 1. The messaging session is established, which may be between two users or between each user and the instant messaging application. 2. The message is received over the messaging session. 7.2.9 Adding a Member to an Established Session This document specifies use of conference control procedures to add a member to an established session. The conference control design team of the SIPPING WG of the IETF is designing these procedures. Two cases are considered: o Adding a third user point-to-point session. Transition a two-user session to a multiparty conference and add a third part to the conference. o Adding a user to a multiparty session, i.e., a session with more than two current users. Houri, et al. Expires December 28, 2003 [Page 39] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.2.10 Transitioning a Two Party Session to a Multiparty Conference and Adding a Third Participant Houri, et al. Expires December 28, 2003 [Page 40] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference AAA Point A Point B Server | | | | | | | | | (1) pt2pt | | | | Session | | | | Established | | | |<-------------->| | | | | | | | (2) Conference | | | | Session | | | | Request | | | |-------------------------------->| | | | | (3) AAA | | | | Request | | | |-------------->| | | | | | | | (4) AAA | | | | Request | |(5) Conference | |<--------------| |Session Response| | | |-------------------------------->| | | | | | | | | | | (6) Conference | | | | Session Ack | | | |<--------------------------------| | | | | | | | | | | (7) Replace | | | | Request | | | |--------------->| | | | | | | | (8) Replace | | | | Response | | | |<---------------| | | | | | | | (9) Release | | | | Request | | | |<---------------| | | | | | | | (10) Release | | | | Response | | | |--------------->| | | | | | | Figure 14 Houri, et al. Expires December 28, 2003 [Page 41] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference End Point A Point B Server Point C | | | | | | | | | |(11) Messaging | | | |Session Request | | | |--------------->| | | | | | | |(12) Messaging | | | |Session Response| | | |<---------------| | | | | | | |(13) Messaging | | | |Session Ack | | | |--------------->| | | (14) Notify | | | | Request | | | |<---------------| | | | | | | | (15) Notify | | | | Response | | | |--------------->| | | | | | | | (16) Join | | | | Request | | | |------------------------------------------------->| | | | | | (17) Join | | | | Response | | | |<-------------------------------------------------| | | |(18) Messaging | | | |Session Request | | | |<-------------- | | | | | | | |(19) Messaging | | | |Session Response| | | |--------------->| | | | | | | | (20) Messaging | | | | Session Ack | | | |<---------------| | | | | | | | | Figure 15 Houri, et al. Expires December 28, 2003 [Page 42] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference End Point A Point B Server Point C | | | | | | | | | | | | | (21) pt2pt | | | | Messaging | | | | Session | | | |<------------------------------------------------>| | | (22) pt2pt | | | | Messaging | | | | Session | (23) pt2pt | | |<-------------->| Messaging | | | | Session | | | |<-------------->| | | | | | | | | | | | | Figure 16 1. A and B have a point-to-point messaging session. A now determines it wishes to add C to the messaging session. 2. A sends a conference session request to the conference server. This informs the conference server of the identity of the conference to be established. Later the actual messaging transport session is initialized. The method by which A finds the conference server is not shown in this flow. 3. The conference server sends an AAA request to the HAAA of the requesting user to verify that user is authorized to use this conference server. 4. The HAAA sends an AAA response to the requesting user. 5. The conference server responds conference session response. 6. A sends a messaging session acknowledge to the conference server. 7. A sends a replace request to B that requests that B release the point-to-point messaging session with A and replace with a point-to-point messaging session to a conference server. 8. B sends a replace response to A. Houri, et al. Expires December 28, 2003 [Page 43] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 9. B sends a release request to A. 10. A responds with a release request response. 11. B sends a messaging session request to the conference server. 12. The conference server sends a messaging session response to B. 13. B sends a messaging session acknowledge to the conference server. 14. B sends a notify request to inform A that it has replaced the connection to A with one to the conference server. 15. A sends a notify response to B. 16. A asks C to join the conference. The endpoint alerts user C and user C makes the decision to join the session. 17. C sends a response to A. 18. C sends a messaging session requst to the conference server. 19. The conference server tells C it is allowed to join the conference. 20. C acknowledges that response. 21. A and the conference server establish a point-to-point messaging session. 22. B and the conference server establish a point-to-point messaging session. 23. C and the conference server establish a point-to-point messaging session. 7.2.11 Adding a User to a Multiparty Session Figure 15 exactly depicts this case, i.e., substitute any other user being for user C in that figure. Houri, et al. Expires December 28, 2003 [Page 44] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.2.12 Leaving a Messaging Session This document specifies use of conference control procedures to delete a member to an established session. The conference control design team of the SIPPING WG of the IETF is designing these procedures. The following shows B dropping off the established conference session. End Conference Point B Server | | | | | (1) Release | | Request | |------------------------->| | | | | | (2) Release | | Response | |<-------------------------| | | | | | (3) Quit | | Messaging Session | |<------------------------>| | | | | Figure 17 1. B sends a Release Request 2. The conference server sends a Release Response to B. 3. B and the conference server terminate the messaging transport session. 7.2.13 Logging Messaging Session Messages Logging messages from a messaging session is outside the scope of the architecture. 7.3 Group Operations Houri, et al. Expires December 28, 2003 [Page 45] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 A group is a nested collection of addresses or identifiers such as an address or record. A group is identified by a single address. Various operations can be performed on a group. The semantics of the operations performed on a group (as opposed to being performed on an individual address) depend on, and should be defined by, each operation. This implies a need for usual group operations such as creation, modification, retrieval, and deletion lists. When the endpoint desires to perform instant messaging (presence) list operations, such as creating or deleting the list, or modifying an existing list, the endpoint establishes security association and then a list management session with its HSP. The endpoint then executes the desired list operation using the list management session. The method by which the endpoint is provisioned with a URL of the list server is outside the scope of this document. OMA has specified IP Provisioning Over the Air and such methods should be adopted or extended if necessary for this application. The following operations are supported: o Add, with a list of URIs to add to the designated list. o Delete, with a list of URIs to delete from the designated list. o A list of existing URIs on the designated list that are to be overwritten with new attributes. o Retrieve the designated list. o Only one list can be affected in a single transaction. 7.3.1 Creating a Group Users or service providers can create a group in more than one way. The list management session requires and authentication of the user and an authorization that the user is permitted to create lists at this HSP. A security session establishes privacy of all list management transactions, to be discussed in section [TBD]. The user sends a create group request, which is acknowledged, to install the list on the Directory. After the transaction is complete, the security and list management session are terminated. The AAA server could be the Home AAA server of the user or could be an AAA server local to the Directory. Houri, et al. Expires December 28, 2003 [Page 46] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End Point A Directory AAA | | | | | | | (1) Create | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Create | | | Group Response | | |<-------------------------| | | | | | | | Figure 18 1. A user sends a create group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to create a group. 3. The AAA sends an AAA response that authorizes the user to create the group. 4. The user creates the group. 5. The directory acknowledges the creation of the group. Houri, et al. Expires December 28, 2003 [Page 47] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.3.2 Deleting a Group Authorized entities may desire to delete group lists. End Point A Directory AAA | | | | | | | (1) Delete | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Delete | | | Group Response | | |<------------------------>| | | | | | | | Figure 19 1. A user sends a delete group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to delete the group. 3. The AAA sends an AAA response that authorizes the user to delete the group. 4. The user creates the group. 5. The directory acknowledges the deletion of the group by sending a group delete response. Houri, et al. Expires December 28, 2003 [Page 48] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.3.3 Modifying_a_Group Authorized entities may desire to modify group lists. End Point A Directory AAA | | | | | | | (1) Modify | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Modify | | | Group Response | | |<------------------------>| | | | | | | | Figure 20 1. A user sends a modify group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to modify the group. 3. The AAA sends an AAA response that authorizes the user to modify the group. 4. The directory acknowledges the modification of the group by sending a group modify response. Houri, et al. Expires December 28, 2003 [Page 49] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.3.4 Retrieving_a_Group Authorized entities may desire to retrieve group lists. End Point A Directory AAA | | | | | | | (1) Retrieve | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Retrieve | | | Group Response | | |<------------------------>| | | | | | | | Figure 21 1. A user sends a retrieve group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to modify the group. 3. The AAA sends an AAA response that authorizes the user to modify the group. 4. The directory sends the group data to the user. Houri, et al. Expires December 28, 2003 [Page 50] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.3.5 Publishing User Management Policy As stated above, wireless resources are often scarce and the user may not desire to receive messages from just anyone, the user may populate a policy in the HSP that controls how incoming messages will be processed. End Point A Directory AAA | | | | | | | (1) edit Reception | | | Policy | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) edit Reception | | | Response | | |<------------------------>| | | | | | | | Figure 22 1. The endpoint establishes a policy management session with the presence application. 2. The presence application verifies the user is authorized to modify the policy by sending an AAA request to the AAA server. 3. The AAA responds to the presence application with an authorization for the user. 4. The endpoint edits the reception policy. 5. The endpoint terminates the policy management session. Houri, et al. Expires December 28, 2003 [Page 51] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.4 Access Deferred Messages An end use may wish to access deferred messages. In order to ensure that the unauthorized entities do not access the user's deferred messages, the IM Application authenticates and authorizes the user to access the messages before sending a request to the message store. End Message Point A Directory AAA Store | | | | | | | | | (1) Retrieve | | | | Message Request | | | |------------------>| | | | | (2) AAA Request | | | |---------------->| | | | | | | | | | | |(3) AAA Response | | | |<----------------| | | | | | | | | | | | | | |< | (4) Retrieve | | | | Message Request | | | |--------------------------------->| | | | | | | (5) Retrieve | | | | Message Response| | | |<---------------------------------| | (6) Retrieve | | | | Message Response | | | |<------------------| | | | | | | Figure 23 1. The user sends a request to the IM Application to retrieve deferred messages. 2. The IM Application authenticates and authorizes the user by sending an AAA Request to the user's HAAA. 3. The HAAA authenticates and authorizes the user and sends an AAA Response to the IM Application authorizing the user to access the Houri, et al. Expires December 28, 2003 [Page 52] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 deferred messages. 4. The IM Application requests the messages by sending a message retrieve request to the Message Store. 5. The Message Store sends the messages to the IM Application. 6. The IM Application sends the messages to the user. 7.5 Presence Operations Houri, et al. Expires December 28, 2003 [Page 53] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.5.1 Publishing Presence The endpoint sends a presence publish request to the presence application via the HSP as in the Figure 24. This request contains the new presence document to publish . The presence application authenticates the user and verifies the user is authorized to store the event at this proxy. End Presence Point A Application AAA | | | | | | | (1) Presence | | | Publish Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Presence | | | Publish Response | | |<-------------------------| | | | | | | | Figure 24 1. The endpoint sends a presence publish request to the presence application. 2. The presence application sends an AAA request to the AAA server to authorize the MS to publish a presence document to this application. 3. The AAA sends an AAA response to the presence application authorizing the presence publish request. 4. The presence application sends a presence publish response to the endpoint. Houri, et al. Expires December 28, 2003 [Page 54] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.5.2 Subscribing to Presence (or a Presence List) The endpoint sends a presence subscription request to the presence application of the presence application that owns the presence state of entity referenced in the logical address. This is shown in Figure 25. The user may be subscribing to events for a specific user or a list of users. End Presence Point A Application AAA | | | | | | | (1) Presence | | | Subscribe Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4)Presence | | | Subscribe Response | | |<-------------------------| | | | | | (5) Presence | | | Notification Response | | |<-------------------------| | | | | | | | Figure 25 1. The endpoint sends a presence subscribe request to the presence application that supports the desired entity. 2. The presence application sends an AAA request to the AAA server to authorize the requesting user to subcribe to the presence of the presentity. 3. The AAA server sends an AAA response to the presence application authorizing the presence subscription request. 4. The presence application sends a presence subscription response Houri, et al. Expires December 28, 2003 [Page 55] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 to the endpoint. 5. The presence application sends a presence notification response to the endpoint. Houri, et al. Expires December 28, 2003 [Page 56] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.5.3 Receiving a Presence Notification An endpoint that has previously subscribed to an event as above. The endpoint receives a notification from the presence application of the presentity or presentity list as follows according to the subscription parameters when the subscription was made. " End Presence Point A Application | | | | | (1) Presence | | Notify Request | |<-------------------------| | | | | | | | (2) Presence | | Notify Response | |<-------------------------| | | | | Figure 26 1. The endpoint receives a presence notification request. 2. The endpoint sends a presence notification response. Houri, et al. Expires December 28, 2003 [Page 57] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 7.5.4 Querying Presence End Presence Point A Application AAA | | | | | | | (1) Presence | | | Query Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Presence | | | Query Response | | |<-------------------------| | | | | | | | Figure 27 1. The endpoint sends a presence query request to the presence application that supports the desired entity. 2. The presence application sends an AAA request to the AAA server to authorize the requesting user to query the presence of the presentity. 3. The HAAA sends an AAA response to the presence application authorizing the presence query request. 4. The presence application sends a presence query response to the endpoint. 8. Access Points and Barriers Several types of Access points or barriers each type of presence and IM system may need to handle. Following are considerations of various access points and barriers Houri, et al. Expires December 28, 2003 [Page 58] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 8.1 Firewalls [TBD. Firewall considerations for presence and IM systems] 8.2 Wireless [TBD. What the presence and IM 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] 8.3 Gateways [TBD. What gateways the presence and IM system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 9. 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 Houri, et al. Expires December 28, 2003 [Page 59] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [TBD. Are there other types of deployments?] 9.1 Enterprise (Single Domains of Trust) 9.1.1 Definition [TBD. Detailed definition and examples of the system] 9.1.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 9.1.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 9.1.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [7]] 9.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.] 9.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.] 9.1.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] Houri, et al. Expires December 28, 2003 [Page 60] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 9.2 Federated Systems 9.2.1 Definition [TBD. Detailed definition and examples of the system] 9.2.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 9.2.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 9.2.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [7]] 9.2.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.2.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.2.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 9.3 Public Systems Interconnecting Houri, et al. Expires December 28, 2003 [Page 61] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 9.3.1 Definition [TBD. Detailed definition and examples of the system] 9.3.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 9.3.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 9.3.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [7]] 9.3.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.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.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 9.4 Open systems 9.4.1 Definition [TBD. Detailed definition and examples of the system] Houri, et al. Expires December 28, 2003 [Page 62] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 9.4.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 9.4.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 9.4.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [7]] 9.4.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.4.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.4.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 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 [7]] Houri, et al. Expires December 28, 2003 [Page 63] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 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.] 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] Houri, et al. Expires December 28, 2003 [Page 64] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 11. The Presence Document [TBD. The definition of a presence document. Mostly referring to the pidf doc [10].] 11.1 Composition From Multiple Sources [TBD. Composing a presence document when there are multiple publishers] 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] Houri, et al. Expires December 28, 2003 [Page 65] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 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.] 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] Houri, et al. Expires December 28, 2003 [Page 66] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 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.] 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.4.1 Offline Messages [TBD. Getting messages that were sent to me while my client is not connected to the system. Two ways are discussed below] Houri, et al. Expires December 28, 2003 [Page 67] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 17.4.2 Queued Offline Messages [TBD. Messages that are delivered to the user when s/he logs in] 17.4.3 Other Offline [TBD. Delivery via email, SMS etc.] 17.5 File Sharing [TBD. Sending files between users. A lot of security and bandwidth issues should be raised here] 17.6 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.7 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.8 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 Security is not a single monolithic property of the system, but rather a series of related but independent properties. This section discusses threats and solutions to address those threats. Generic threats considered are: 1. Unauthorized usage of network SIP/SIMPLE servers, either as a new user or an existing user, of the messaging and presence services Houri, et al. Expires December 28, 2003 [Page 68] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 2. Rogue network entity representation as being an authentic network entity to the endpoint 3. Eavesdropping or altering a message 4. Unauthorized access and modification of configuration data or stored messages of another user 18.1 Authentication Mutual authentication is required: o Authentication of the endpoint by service elements o Authentication of service elements by the endpoint Note that authentication is separate from authorization to use the network. A user may be authenticated but nevertheless refused service. 18.2 Network Authentication of the endpoint It is possible that an attacker represent itself to service elements as a valid endpoint. This could occur by the attacker attempting to register or send SIP/SIMPLE packets using the identity of a valid endpoint. The general solution to this type of threat is cryptographic authentication, which could be provided at the SIP layer or at a lower layer. SIP supports a number of challenge response mechanisms such as digest authentication [2]. The HSP or other proxies can perform SIP authentication using the AAA system. Possible lower layer security systems include TLS or IKE/IPSec. If TLS is used, the endpoint has to have a certificate verifiable by a PKI. This is also true for IKE the control protocol for IPSec , however, IPSec can also be used with pre-shared keys that exist between the endpoint and the service elements or the AAA server that can make them available to the service elements. In some cases the authentication may be performed by one service element on behalf of other service elements. This may be referred to a transitive trust model. For this to be applicable, there must be a secure relationship between the sevice elements. 18.3 Endpoint Authentication of the Service Elements It is important that the endpoint determine that it is communicating Houri, et al. Expires December 28, 2003 [Page 69] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 with legitimate service elements. TLS and IPSec provide hop-by-hop mechanisms. These allow the endpoint to verify the identity of the first service element in a chain of service elements. The endpoint must generally rely on the trust model then to establish the identity of remote service elements. Example is the use sips uri. 18.4 Authorization for Service Having authenticated the user, the service elements can use the AAA system to make authorization decisions relative to specific service requests. Another way to authorize the user is certificate attributes in the user's certificate. This assumes the service elements have verified the user's certificate. 18.5 Integrity and Privacy of SIP/SIMPLE Messages An attacker may attempt to eavesdrop or alter messages. General solutions to these types of threats are to use: o Secure transport protocols such as IPSec or TLS between the endpoint and the HSP or between the endpoint and the first SIP proxy encountered by the SIP traffic. There needs to be a transitive trust on the part of the endpoint with all proxies involved. Example is the use of sips uri. o Security transport protocols such as IPSec or TLS between the endpoint and the conference bridge. There needs to be a trust on the part of the endpoint and the conference bridge function involved. Example is the use of sips uri. o /MIME to protect SIP/SIMPLE message bodies; this security is between and users, i.e., is end to end. However, in some commercial applications the message store itself is viewed as a "user" if the messages may need to be audited later, e.g., the Security Exchange Commission if it needs to review messages from brokers to investors. o It is possible to use both security transport protocols and S/ MIME: the former protects the SIP/SIMPLE messages as they traverse public facilities and the S/MIME protects the message bodies end to end. 18.6 Configuration of Subscriber Data or Stored Messages An attacker may attempt an unauthorized access and modification of Houri, et al. Expires December 28, 2003 [Page 70] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 configuration data of another user. An example of configured data is instant message groups. The general solution to this threat is to o Authenticate the user; this is likely a separate authentication as the data is stored in separate systems outside the scope of the SIP proxies. o Verify that the authenticated user is authorized to access or modify the specific data for a specific user. o Apply encryption and integrity on the data access control messages. o The encryption and integrity should operate between the endpoint and the directory or database that stores the user's configuration data or deferred messages. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [4] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [5] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002. [6] 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. [7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. Houri, et al. Expires December 28, 2003 [Page 71] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [10] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [11] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [12] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf-impp-pres-03 (work in progress), May 2003. [13] Peterson, J., "Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress), May 2003. [14] Peterson, J., "Address Resolution for Instant Messaging and Presence", draft-ietf-impp-srv-03 (work in progress), May 2003. [15] Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE Presence and Instant Messaging", draft-ietf-simple-cpim-mapping-01 (work in progress), June 2002. [16] Kyzivat, P., "Requirements for SIP Capabilities in PIDF", draft-kyzivat-simple-prescaps-reqts-00 (work in progress), October 2002. [17] Lonnfors, M. and K. Kiss, "SIMPLE PIDF presence capabilities extension", draft-lonnfors-simple-prescaps-ext-01 (work in progress), June 2003. [18] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", draft-ietf-simple-data-req-02 (work in progress), April 2003. [19] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-04 (work in progress), June 2003. [20] Isomaki, M., "Semantic Description of SIMPLE List Manipulation Operations", draft-isomaki-simple-list-man-sem-00 (work in progress), November 2002. [21] Campbell, B., "Instant Message Transport Sessions using the CPIM Message Format", draft-campbell-simple-cpimmsg-sessions-00 (work in progress), October 2002. [22] Campbell, B. and J. Rosenberg, "Instant Message Sessions in Houri, et al. Expires December 28, 2003 [Page 72] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 SIMPLE", draft-campbell-simple-im-sessions-01 (work in progress), March 2003. [23] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-00 (work in progress), December 2002. [24] Sparks, R., "Establishing jabber Messaging Sessions with the Session Initiation Protocol", draft-sparks-simple-jabber-sessions-00 (work in progress), October 2002. [25] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [26] Khartabil, H., "Event Notification Filtering for Presence", draft-khartabil-simple-presence-filter-00 (work in progress), January 2003. [27] Costa-Requena, J. and M. Lonnfors, "Requirements for Efficient Delivery of Presence Information", draft-lonnfors-simple-presinfo-deliv-reqs-00 (work in progress), January 2003. [28] Costa-Requena, J. and E. Leppanen, "Partial Notification of Presence Information", draft-lonnofors-simple-partial-notify-00 (work in progress), January 2003. [29] Moran, T. and S. Addagatla, "Requirements for Presence specific Event Notification Filters", draft-moran-simple-pres-filter-reqs-00 (work in progress), January 2003. [30] Campbell, B., "SIMPLE Presence Publication Requirements", draft-ietf-simple-publish-reqs-00 (work in progress), February 2003. [31] Niemi, A., "SIP Specific Data Publication Framework", draft-niemi-simple-publish-framework-00 (work in progress), September 2002. [32] Campbell, B., "SIMPLE Presence Publication Mechanism", draft-olson-simple-publish-02 (work in progress), March 2003. [33] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", Houri, et al. Expires December 28, 2003 [Page 73] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 draft-ietf-simple-winfo-format-04 (work in progress), January 2003. [34] 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. [35] Kiss, K., "Requirements for Presence Service in 3GPP Wireless Systems", draft-kiss-simple-presence-wireless-reqs-02 (work in progress), March 2003. [36] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-01 (work in progress), March 2003. [37] Niemi, A., "Requirements for Limiting the Rate of Event Notifications", draft-niemi-sipping-event-throttle-reqs-01 (work in progress), March 2003. [38] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing-framework-01 (work in progress), February 2003. [39] 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 [40] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", draft-ietf-xmpp-im-13 (work in progress), June 2003. Authors' Addresses Avshalom Houri IBM Science Park Building 18/D Rehovot Israel Phone: +972 8 9409761 Ext. 123 EMail: avshalom@il.ibm.com Houri, et al. Expires December 28, 2003 [Page 74] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Tom Hiller Lucent Chicago, IL USA Phone: EMail: tomhiller@lucent.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, Dean Willis, Robert Sparks, Jon Peterson, and, Ben Campbell. Houri, et al. Expires December 28, 2003 [Page 75] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 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, et al. Expires December 28, 2003 [Page 76] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Houri, et al. Expires December 28, 2003 [Page 77]