Internet Engineering Task Force Internet Draft H. Schulzrinne Columbia U. P. Kyzivat Cisco V. Gurbani Lucent J. Rosenberg dynamicsoft draft-schulzrinne-simple-rpids-01.txt February 18, 2003 Expires: August 2003 RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The Rich Presence Information Data Format for SIP (RPIDS) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior and/or be delivered to watchers. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. H. Schulzrinne et. al. [Page 1] Internet Draft RPIDS February 18, 2003 1 Introduction The PIDF definition [1] describes a basic presence infornation data format for exchanging presence information in CPIM-compliant systems. It consists of a root element, zero or more elements carrying presence information, zero or more elements and zero or more extension elements from other name spaces. Each tuple defines a basic status of either "open" or "closed". This document provides additional status information for presentities and defines a Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this information. This extension has two main goals: 1. Provide rich presence indication that is at least as powerful as common commercial presence systems. Such feature-parity simplifies transition to CPIM-compliant systems, both in terms of user acceptance and protocol conversion. 2. Maintain compatibility with PIDF, so that PIDF-only watchers and gateways can continue to function properly. The document here is complementary to the device capability descriptions derived from caller preferences [8]. Both can be used as extensions within the same PIDF document. We make no assumptions how the information in the RPIDS is generated. Experience has shown that users are not always diligent about updating their presence status. Thus, we want to make it as easy as possible to derive RPIDS information from other information sources, such as calendars, the status of communication devices such as telephones, typing activity and physical presence detectors as commonly found in energy-management systems. The information in a presence document can be generated by a single entity or can be composed from information published by multiple entities. Many of the elements correspond to data commonly found in personal calendars. Thus, we attempted to align some of the extensions with the usage found in calendar formats such as iCal [9] and xCal [10], as noted below. Note that PIDF documents and this extension can be used in two different contexts, namely by the presentity to publish its presence H. Schulzrinne et. al. [Page 2] Internet Draft RPIDS February 18, 2003 status and by the presence server to notify some set of watchers. The presence server MAY compose, translate or filter the published presence state before delivering customized presence information to the watcher. For example, it may merge presence information from multiple PUAs, remove whole elements, translate values in elements or remove information from elements. Mechanisms that filter calls and other communications to the presentity can subscribe to this presence information just like a regular watcher and in turn generate automated rules, such as scripts [11], that govern the actual communications behavior of the presentity. The flow diagram below illustrates this process. presentity | --> publish | --> PA (filter) --> notification 1 to A, B, C --> notification 2 to D, E --> notification 3 to F --> notification 4 to script gen. 2 RPIDS Features Below, we summarize and motivate the major additional features that RPIDS adds to PIDF. The PIDF definition does not clearly describe what a represents. We add an element (Section 6.3) that labels each tupel as being a presentity, a group of presentities or a device. While the PIDF definition describes which means of communications are available for a presentity, it does not describe the activity that the presentity is currently engaged in. The (Section 6.6) element adds this information. To help the watcher gauge the appropriateness of different types of communications, we indicate the type of place the user is currently in, via the element (Section 6.4). PIDF defines a element indicating the date and time of the status change of a tuple. RPIDS adds a validity period for status values, and , as a hint how long the current status is likely to be valid (Section 6.7 and Section 6.8). H. Schulzrinne et. al. [Page 3] Internet Draft RPIDS February 18, 2003 The (Section 6.9) and (Section 6.10) provide information on when the device has last been used. Presence information can provide hints as to how interruptible the presentity is, thus aiding in finding a time and manner of communications that is mutually convenient for both watcher and presentity. The "priority" callee capability described in [12] and, by reference, included in [8] offers this capability. This appears to be more expressive than the simple "do-not-disturb" indication found in some IM and presence systems. An important sub-case is that a presentity is interruptible only under unusual circumstances, after mediation by some, typically human, authority such as a secretary or supervisor. We allow the presentity to convey that certain contact addresses actually belong to a different person, presumably one that can either interrupt the presentity or otherwise assist. The (Section 6.11) element allows to indicate that a particular tuple refers to a different principal or presentity. PIDF only defines tuples for one presentity. In many cases, it is useful to allow presentities to refer to groups of other presentities. For example, a presentity all@example.com might consist of marketing@example.com , engineering@example.com , finance@example.com engineering@example.com might in turn have presentities alice@example.com , bob@example.org (an intern), carol@example.com , We add multiple layer to PIDF by defining an extension (Section 6.13) that can in turn contain multiple PIDF presence elements, thus allowing recursion. We establish the convention that a tuple that has no contact address indicates face-to-face communications. PIDF already notes that "there might be tuples not related to any communications means". We generally assume that the presence element describes a single human being or a group of humans. However, this is not required. A presentity can also be a "bot" or "avatar", for example. Note that this document does not defined a new content type. Rather, it inherits the content type from [1], namely application/cpim- pidf+xml H. Schulzrinne et. al. [Page 4] Internet Draft RPIDS February 18, 2003 Other useful information about tuples is defined in [8]. In particular, that document allows to describe the media types supported by a contact address, whether it supports recording and the minimum priority of calls admitted. 3 Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document [2]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein. The key words MUST, MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP XX, RFC 2119 [3]. 4 The Meaning of "open" and "closed" PIDF describes the basic status values of "open" or "closed" only as "have meanings of general availability for other communications means". We define "closed" in our context as meaning that communication to the contact address will in all likelihood not succeed, is undesired or will not reach the intended party. (For example, a presentity may include a hotel phone number as a contact. After check-out, the phone number will still ring, but reach the chambermaid or the next guest. Thus, it would be declared "closed".) For "pres" contacts, "closed" means that no presence status information is available. The interpretation of "closed" was chosen since there is no other status value to indicate that a communications address is not reachable. Omitting the element does not work since it would confuse watchers that have not previously seen an "open" status for the same contact address. 5 Groups of Presentities In many practical applications, a watcher wants to subscribe to groups of presentities rather than individuals. For example, the group membership may change over time and it may thus be difficult to subscribe to all members. If the group is large, the effort of subscription and their renewals may add significant burden to the watcher. There are several different approaches to group subscriptions: Group only: The watcher subscribes to a group and only cares H. Schulzrinne et. al. [Page 5] Internet Draft RPIDS February 18, 2003 about the status of the group as a whole. There is no protocol difference to subscribing to an individual and thus no need for extensions. Subscription only: The watcher subscribes to a group, but receives individual notifications. This does not require an extensions to PIDF. However, it is useful to indicate in the presence document which presentity caused the notification to be sent, as the watcher otherwise has no idea why he received a particular notification. We add a element to describe this relationship. Subscription with redirection: The watcher subscribes to a group. The presence document identifies the group members and allows the watcher to subscribe to each member individually. In PIDF, this is expressed by a "pres" URI in the element. Each such presentity can in turn be a group, recursively. TBD: How does the watcher find out if group membership has changed? We don't want to list all members in each PIDF notification. This basically becomes draft-roach-sip-list-template. Subscription with full status: A single notification contains tuples from all presentities that have changed status since the last notification. We allow "recursive" presence definitions, where a element contains other elements, encapsulated as (Section 6.13). 6 RPIDS Elements 6.1 Introduction Below, we describe the RPIDS elements in detail. , , , ,