idnits 2.17.1 draft-ietf-simple-rpids-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2003) is 7607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 774, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '3') ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '12') (Obsoleted by RFC 5545) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne (ed.) 4 Columbia U. 5 draft-ietf-simple-rpids-01.txt 6 June 29, 2003 7 Expires: December 2003 9 RPIDS -- Rich Presence Information Data Format for Presence Based 10 on the Session Initiation Protocol (SIP) 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Rich Presence Information Data Format for the Session Initiation 36 Protocol (SIP) (RPIDS) adds elements to the Presence Information Data 37 Format (PIDF) that provide additional information about the 38 presentity and its contacts. This information can be translated into 39 call routing behavior or be delivered to watchers. The information is 40 designed so that much of it can be derived automatically, e.g., from 41 calendar files or user activity. 43 1 Introduction 45 The PIDF definition [1] describes a basic presence information data 46 format for exchanging presence information in CPIM-compliant systems. 47 It consists of a root element, zero or more 48 elements carrying presence information, zero or more elements 49 and zero or more extension elements from other name spaces. Each 50 tuple defines a basic status of either "open" or "closed". 52 This document provides additional status information for presentities 53 and defines a Rich Presence Information Data Format for Presence 54 Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this 55 information. 57 This extension has three main goals: 59 1. Provide rich presence indication that is at least as 60 powerful as common commercial presence systems. Such 61 feature-parity simplifies transition to CPIM-compliant 62 systems, both in terms of user acceptance and protocol 63 conversion. 65 2. Maintain backwards-compatibility with PIDF, so that PIDF- 66 only watchers and gateways can continue to function 67 properly, naturally without access to the functionality 68 described here. 70 We make no assumptions how the information in the RPIDS is generated. 71 Experience has shown that users are not always diligent about 72 updating their presence status. Thus, we want to make it as easy as 73 possible to derive RPIDS information from other information sources, 74 such as calendars, the status of communication devices such as 75 telephones, typing activity and physical presence detectors as 76 commonly found in energy-management systems. 78 The information in a presence document can be generated by a single 79 entity or can be composed from information published by multiple 80 entities. 82 Many of the elements correspond to data commonly found in personal 83 calendars. Thus, we attempted to align some of the extensions with 84 the usage found in calendar formats such as iCal [12] and xCal [13], 85 as noted below. 87 Note that PIDF documents and this extension can be used in two 88 different contexts, namely by the presentity to publish its presence 89 status and by the presence server to notify some set of watchers. The 90 presence server MAY compose, translate or filter the published 91 presence state before delivering customized presence information to 92 the watcher. For example, it may merge presence information from 93 multiple PUAs, remove whole elements, translate values in elements or 94 remove information from elements. Mechanisms that filter calls and 95 other communications to the presentity can subscribe to this presence 96 information just like a regular watcher and in turn generate 97 automated rules, such as scripts [14], that govern the actual 98 communications behavior of the presentity. 100 The flow diagram below illustrates this process. 102 presentity 103 | 104 --> publish 105 | 106 --> PA (filter) 107 --> notification 1 to A, B, C 108 --> notification 2 to D, E 109 --> notification 3 to F 110 --> notification 4 to script gen. 112 2 RPIDS Features 114 Below, we summarize and motivate the major additional features that 115 RPIDS adds to PIDF. 117 The PIDF definition does not clearly describe what a 118 represents. We add an attribute (Section 6.4) that allows a 119 presentity to label tuples in ways that make sense to the presentity, 120 e.g., to group similar tuples by name. 122 While the PIDF definition describes which means of communications are 123 available for a presentity, it does not describe the activity that 124 the presentity is currently engaged in. The (Section 6.2) 125 element adds this information. 127 The (Section 6.7) element indicates when the device was last 128 used or simply whether it has been idle. 130 To help the watcher gauge the appropriateness of different types of 131 communications, we indicate the type of place the user is currently 132 in, via the element (Section 6.9) and hint at the privacy 133 available via . 135 PIDF defines a element indicating the date and time of 136 the status change of a tuple. RPIDS adds a validity period for status 137 values, and , as a hint how long the current status is 138 likely to be valid (Section 6.5 and Section 6.13). 140 Information about a tuple can be conveyed using the , 141 and elements. 143 An important sub-case is that a presentity is interruptible only 144 under unusual circumstances, after mediation by some, typically 145 human, authority such as a secretary or supervisor. We allow the 146 presentity to convey that certain contact addresses actually belong 147 to a different person, presumably one that can either interrupt the 148 presentity or otherwise assist. The (Section 6.11) 149 element allows to indicate that a particular tuple refers to a 150 different principal or presentity. 152 The PIDF document format [1] defines a element which may 153 appear once inside every element. The content of the 154 element encodes the CONTACT ADDRESS and CONTACT MEANS as 155 defined in [3]. The element is defined to be an URI. This 156 URI can be of any URI scheme. Some URI schemes uniquely identify the 157 application the tuple intends to describe (e.g., "im" URIs). However, 158 this is not be the case for all schemes. For example, a SIP URI can 159 represent different kinds of applications, including voice, video, or 160 messaging. If it is not known by other means, it can be hard for 161 applications processing the presence document containing only SIP URI 162 contact addresses to know what particular application the tuple 163 intends to describe. Also, watchers receiving presence information 164 would benefit for getting more descriptive information about what 165 particular communication means or applications are supported by the 166 presentity. 168 We generally assume that the presence element describes a single 169 human being or a group of humans. However, this is not required. A 170 presentity can also be a "bot" or "avatar", for example. 172 Note that this document does not defined a new content type. Rather, 173 it inherits the content type from [1], namely application/cpim- 174 pidf+xml 176 3 Scope 178 This extension does not replace media negotiation mechanisms defined 179 for SIP (e.g. SDP [4]), therefore media negotiation (e.g., choice of 180 voice and video codecs) MUST be performed according to [5]. This 181 extension is only aimed to give the watchers hints about the 182 presentity's preferences, willingness and capabilities to communicate 183 before watchers initiate SIP-based communication with the presentity. 185 4 Terminology and Conventions 187 This memo makes use of the vocabulary defined in the IMPP Model 188 document [3]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 189 SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are 190 used in the same meaning as defined therein. The key words MUST, 191 MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL 192 in this document are to be interpreted as described in BCP XX, RFC 193 2119 [6]. 195 5 The Meaning of "open" and "closed" 197 PIDF describes the basic status values of "open" or "closed" only as 198 "have meanings of general availability for other communications 199 means". We define "closed" in our context as meaning that 200 communication to the contact address will in all likelihood not 201 succeed, is undesired or will not reach the intended party. (For 202 example, a presentity may include a hotel phone number as a contact. 203 After check-out, the phone number will still ring, but reach the 204 chambermaid or the next guest. Thus, it would be declared "closed".) 205 For "pres" contacts, "closed" means that no presence status 206 information is available. 208 The interpretation of "closed" was chosen since there is no 209 other status value to indicate that a communications 210 address is not reachable. Omitting the element 211 does not work since it would confuse watchers that have not 212 previously seen an "open" status for the same contact 213 address. 215 6 RPIDS Elements 217 6.1 Introduction 219 Below, we describe the RPIDS elements in detail. , 220 , , ,