idnits 2.17.1 draft-ietf-simple-rpids-00.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 22, 2003) is 7612 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 766, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 793, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 815, 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-00.txt 6 June 22, 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. The capabilities information is 42 compatible with the caller preferences extensions to SIP, but does 43 not depend on these. 45 1 Introduction 47 The PIDF definition [1] describes a basic presence infornation data 48 format for exchanging presence information in CPIM-compliant systems. 49 It consists of a root element, zero or more 50 elements carrying presence information, zero or more elements 51 and zero or more extension elements from other name spaces. Each 52 tuple defines a basic status of either "open" or "closed". 54 This document provides additional status information for presentities 55 and defines a Rich Presence Information Data Format for Presence 56 Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this 57 information. 59 This extension has three main goals: 61 1. Provide rich presence indication that is at least as 62 powerful as common commercial presence systems. Such 63 feature-parity simplifies transition to CPIM-compliant 64 systems, both in terms of user acceptance and protocol 65 conversion. 67 2. Maintain backwards-compatibility with PIDF, so that PIDF- 68 only watchers and gateways can continue to function 69 properly, naturally without access to the functionality 70 described here. 72 We make no assumptions how the information in the RPIDS is generated. 73 Experience has shown that users are not always diligent about 74 updating their presence status. Thus, we want to make it as easy as 75 possible to derive RPIDS information from other information sources, 76 such as calendars, the status of communication devices such as 77 telephones, typing activity and physical presence detectors as 78 commonly found in energy-management systems. 80 The information in a presence document can be generated by a single 81 entity or can be composed from information published by multiple 82 entities. 84 Many of the elements correspond to data commonly found in personal 85 calendars. Thus, we attempted to align some of the extensions with 86 the usage found in calendar formats such as iCal [12] and xCal [13], 87 as noted below. 89 Note that PIDF documents and this extension can be used in two 90 different contexts, namely by the presentity to publish its presence 91 status and by the presence server to notify some set of watchers. The 92 presence server MAY compose, translate or filter the published 93 presence state before delivering customized presence information to 94 the watcher. For example, it may merge presence information from 95 multiple PUAs, remove whole elements, translate values in elements or 96 remove information from elements. Mechanisms that filter calls and 97 other communications to the presentity can subscribe to this presence 98 information just like a regular watcher and in turn generate 99 automated rules, such as scripts [14], that govern the actual 100 communications behavior of the presentity. 102 The flow diagram below illustrates this process. 104 presentity 105 | 106 --> publish 107 | 108 --> PA (filter) 109 --> notification 1 to A, B, C 110 --> notification 2 to D, E 111 --> notification 3 to F 112 --> notification 4 to script gen. 114 2 RPIDS Features 116 Below, we summarize and motivate the major additional features that 117 RPIDS adds to PIDF. 119 The PIDF definition does not clearly describe what a 120 represents. We add an element (Section 6.6) that labels each 121 tuple as being a presentity, a group of presentities or a device. 123 While the PIDF definition describes which means of communications are 124 available for a presentity, it does not describe the activity that 125 the presentity is currently engaged in. The (Section 6.4) 126 element adds this information. 128 To help the watcher gauge the appropriateness of different types of 129 communications, we indicate the type of place the user is currently 130 in, via the element (Section 6.12). 132 PIDF defines a element indicating the date and time of 133 the status change of a tuple. RPIDS adds a validity period for status 134 values, and , as a hint how long the current status is 135 likely to be valid (Section 6.7 and Section 6.16). 137 The (Section 6.2) and (Section 6.10) provide 138 information on when the device has last been used. 140 Presence information can provide hints as to how interruptible the 141 presentity is, thus aiding in finding a time and manner of 142 communications that is mutually convenient for both watcher and 143 presentity. We express this as a SIP priority value, as this appears 144 to be more expressive than the simple "do-not-disturb" indication 145 found in some IM and presence systems. 147 An important sub-case is that a presentity is interruptible only 148 under unusual circumstances, after mediation by some, typically 149 human, authority such as a secretary or supervisor. We allow the 150 presentity to convey that certain contact addresses actually belong 151 to a different person, presumably one that can either interrupt the 152 presentity or otherwise assist. The (Section 6.14) 153 element allows to indicate that a particular tuple refers to a 154 different principal or presentity. 156 The PIDF document format [1] defines a element which may 157 appear once inside every element. The content of the 158 element encodes the CONTACT ADDRESS and CONTACT MEANS as 159 defined in [3]. The element is defined to be an URI. This 160 URI can be of any URI scheme. Some URI schemes uniquely identify the 161 application the tuple intends to describe (e.g., "im" URIs). However, 162 this is not be the case for all schemes. For example, a SIP URI can 163 represent different kinds of applications, including voice, video, or 164 messaging. If it is not known by other means, it can be hard for 165 applications processing the presence document containing only SIP URI 166 contact addresses to know what particular application the tuple 167 intends to describe. Also, watchers receiving presence information 168 would benefit for getting more descriptive information about what 169 particular communication means or applications are supported by the 170 presentity. 172 PIDF only defines tuples for one presentity. In many cases, it is 173 useful to allow presentities to refer to groups of other 174 presentities. For example, a presentity all@example.com might 175 consist of 177 marketing@example.com , 178 engineering@example.com , finance@example.com 180 engineering@example.com might in turn have presentities 182 alice@example.com , 183 bob@example.org (an intern), carol@example.com 185 We establish the convention that a tuple that has no contact address 186 indicates face-to-face communications. PIDF already notes that "there 187 might be tuples not related to any communications means". 189 We generally assume that the presence element describes a single 190 human being or a group of humans. However, this is not required. A 191 presentity can also be a "bot" or "avatar", for example. 193 Note that this document does not defined a new content type. Rather, 194 it inherits the content type from [1], namely application/cpim- 195 pidf+xml 197 3 Scope 199 This extension does not replace media negotiation mechanisms defined 200 for SIP (e.g. SDP [4]), therefore media negotiation (e.g., choice of 201 voice and video codecs) MUST be performed according to [5]. This 202 extension is only aimed to give the watchers hints about the 203 presentity's preferences, willingness and capabilities to communicate 204 before watchers initiate SIP-based communication with the presentity. 206 4 Terminology and Conventions 208 This memo makes use of the vocabulary defined in the IMPP Model 209 document [3]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 210 SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are 211 used in the same meaning as defined therein. The key words MUST, 212 MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL 213 in this document are to be interpreted as described in BCP XX, RFC 214 2119 [6]. 216 5 The Meaning of "open" and "closed" 218 PIDF describes the basic status values of "open" or "closed" only as 219 "have meanings of general availability for other communications 220 means". We define "closed" in our context as meaning that 221 communication to the contact address will in all likelihood not 222 succeed, is undesired or will not reach the intended party. (For 223 example, a presentity may include a hotel phone number as a contact. 224 After check-out, the phone number will still ring, but reach the 225 chambermaid or the next guest. Thus, it would be declared "closed".) 226 For "pres" contacts, "closed" means that no presence status 227 information is available. 229 The interpretation of "closed" was chosen since there is no 230 other status value to indicate that a communications 231 address is not reachable. Omitting the element 232 does not work since it would confuse watchers that have not 233 previously seen an "open" status for the same contact 234 address. 236 6 RPIDS Elements 238 6.1 Introduction 240 Below, we describe the RPIDS elements in detail. , 241 , , , ,