idnits 2.17.00 (12 Aug 2021) /tmp/idnits52811/draft-ietf-simple-presence-data-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1713. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1729), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 57 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 28, 2004) is 6443 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: '8' is defined on line 1613, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1650, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1673, but no explicit reference was found in the text == Outdated reference: draft-ietf-simple-rpid has been published as RFC 4480 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 == Outdated reference: draft-ietf-sip-publish has been published as RFC 3903 == Outdated reference: draft-ietf-simple-prescaps-ext has been published as RFC 5196 == Outdated reference: draft-ietf-simple-filter-format has been published as RFC 4661 == Outdated reference: draft-ietf-simple-future has been published as RFC 4481 == Outdated reference: draft-ietf-simple-cipid has been published as RFC 4482 == Outdated reference: draft-wilde-sms-uri has been published as RFC 5724 == Outdated reference: draft-mealling-uuid-urn has been published as RFC 4122 == Outdated reference: draft-ietf-sipping-dialog-package has been published as RFC 4235 == Outdated reference: draft-ietf-iptel-rfc2806bis has been published as RFC 3966 == Outdated reference: draft-ietf-simple-xcap-pidf-manipulation-usage has been published as RFC 4827 Summary: 8 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: March 29, 2005 September 28, 2004 5 A Data Model for Presence 6 draft-ietf-simple-presence-data-model-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 29, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines the underlying data model and data processing 40 operations used by Session Initiation Protocol (SIP) for Instant 41 Messaging Leveraging Presence Extensions (SIMPLE) presence agents. 42 The data model provides guidance on how to map various communications 43 systems into presence documents in a consistent fashion. The data 44 processing operations described here include composition, privacy 45 filtering, and watcher filtering. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1 Person . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 3.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.3 Device . . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 4. Motivation for the Model . . . . . . . . . . . . . . . . . . . 12 56 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 5.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 14 58 5.1.1 Person . . . . . . . . . . . . . . . . . . . . . . . . 14 59 5.1.2 Device . . . . . . . . . . . . . . . . . . . . . . . . 16 60 6. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 6.1 Reporting . . . . . . . . . . . . . . . . . . . . . . . . 17 62 6.2 Overriding . . . . . . . . . . . . . . . . . . . . . . . . 18 63 7. Presence Server Processing . . . . . . . . . . . . . . . . . . 19 64 7.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . 20 65 7.2 Composition . . . . . . . . . . . . . . . . . . . . . . . 22 66 7.2.1 Correlation . . . . . . . . . . . . . . . . . . . . . 22 67 7.2.2 Conflict Resolution . . . . . . . . . . . . . . . . . 22 68 7.2.3 Merging . . . . . . . . . . . . . . . . . . . . . . . 24 69 7.2.4 Splitting . . . . . . . . . . . . . . . . . . . . . . 26 70 7.3 Privacy Filtering . . . . . . . . . . . . . . . . . . . . 27 71 7.4 Watcher Filtering . . . . . . . . . . . . . . . . . . . . 27 72 7.5 Post-Processing Composition . . . . . . . . . . . . . . . 27 73 8. Extending the Presence Model . . . . . . . . . . . . . . . . . 28 74 9. Example Presence Documents . . . . . . . . . . . . . . . . . . 28 75 9.1 Basic IM Client . . . . . . . . . . . . . . . . . . . . . 28 76 9.2 VoIP Application . . . . . . . . . . . . . . . . . . . . . 31 77 9.3 Cellphone . . . . . . . . . . . . . . . . . . . . . . . . 32 78 10. Security Considerations . . . . . . . . . . . . . . . . . . 35 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 80 12. Informative References . . . . . . . . . . . . . . . . . . . 36 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 82 Intellectual Property and Copyright Statements . . . . . . . . 39 84 1. Introduction 86 Presence conveys the ability and willingness of a user to communicate 87 across a set of devices. RFC 2778 [1] defines a model and 88 terminology for describing systems that provide presence information. 89 RFC 3863 [3] defines an XML document format for representing presence 90 information. In these specifications, presence information is 91 modeled as a series of tuples, each of which contains a status, 92 communications address, and other markup. However, neither 93 specification gives guidance on exactly what a tuple is meant to 94 model, and how to map real world communications systems (and in 95 particular, those built around the Session Initiation Protocol (SIP) 96 [4]) into a presence document. 98 In particular, several important concepts are not clearly modeled or 99 well delineated by RFC 2778. These are: 100 Service: A communications service, such as instant messaging or 101 telephony, is a system for interaction between users that provides 102 certain modalities. 103 Device: A communications device is a physical component that a user 104 interacts with in order to make or receive communications. 105 Examples are a phone, PDA or PC. 106 Person: A person is the end user, and for the purposes of presence, 107 is characterized by states, such as "busy" or "sad" which impact 108 their ability and willingness to communicate. 110 This specification defines these concepts more fully by means of a 111 presence data model, and concretely defines how to take real world 112 systems and map them into presence documents using that model. 114 Furthermore, in SIMPLE systems, presence documents are processed 115 extensively by presence user agents, presence agents, and watchers. 116 Other specifications, such as the presence event package [5] and the 117 PUBLISH method [12] document the protocol interfaces for moving 118 presence documents between these entities. However, none of these 119 specifications define the behaviors these elements can exhibit in 120 terms of processing those documents. This specification defines 121 those procedures, including composition, privacy filtering, and 122 watcher filtering, in more detail. 124 2. Definitions 126 This document makes use of many new terms, which are defined here. 127 Device: A device models the physical environment in which services 128 manifest themselves for users. Devices have characteristics which 129 are useful in allowing a user to make a choice about which 130 communications service to use. 132 Service: A service models a form of communications that can be used 133 to interact with the user. 134 Person: A person models the human user and their states that are 135 relevant to presence systems. 136 Presentity: A presentity combines devices, services and person 137 information for a complete picture of a user's presence status on 138 the network. 139 Presentity URI: A URI that acts as a unique identifier for a 140 presentity, and provides a handle for obtaining presence 141 information about that presentity. 142 Data Element: One of the device, service, or person parts of a 143 presence document. 144 Composition: The act of combining a set of presence and event data 145 about a presentity into a coherent picture of the state of that 146 presentity. 147 Raw Presence Document: The result of an initial composition 148 operation, before privacy and watcher filtering operations have 149 been applied. 150 Collection: The process of obtaining the set of event state that is 151 necessary for performing the composition operation. 152 Merging: Merging is an operation that allows a presence server to 153 combine together a set of different services or devices into a 154 single composite service or device. 155 Privacy Filtering: The act of applying permissions to a presence 156 document for the purposes of removing information that a watcher 157 is not authorized to see. 158 Watcher filtering The act of removing information from a presence 159 document at the request of a watcher, to reduce the information 160 flowing to that watcher. 161 Pivot: A presence attribute used to select a set of services or 162 devices that are to be combined as part of a composition 163 operation. 164 View: A view represents a stream of presence documents generated by a 165 presentity after composition and authorization policies have been 166 applied. Depending on how these policies are structured, each 167 watcher to a presentity may get a different view, or they may all 168 get the same view. 169 Status: Dynamic information about a service, person or device. 170 Characteristics: Static information about a service, person or 171 device. Useful in providing context that identifies the service 172 or device as different from another service or device. 173 A service or characteristic. It represents a single piece of 174 presence information. 175 Publication: The act of pushing a piece of event state, including 176 presence, to a state agent, such as a presence server. 178 Back end subscription: A subscription made from a state agent, such 179 as a presence server, to a source of presence, for the purpose of 180 collecting event state in order to perform composition. 181 Device View: A presence document obtained by composing together 182 services with the same value of the device ID attribute. 183 Presentity View: A presence document obtained by composing together 184 all services into a single tuple. 185 Service View: A presence document whereby the compositor has not 186 combined together services, or it has combined them, but not used 187 the device ID as a pivot. 188 Splitting: Splitting is the process of taking a single service or 189 device data element, and splitting into two services or devices. 190 Reporting: When a service or device publishes presence data about 191 itself, it is called reporting. Reporting is in contrast to 192 overriding, where a software agent publishes about a different 193 service or device. 194 Overriding: When a service or device publishes presence information 195 about a different service or device, in an attempt to correct or 196 modify that data. 198 3. The Model 200 +--------------------------------------------------------------------+ 201 | | 202 | +----------------+ | 203 | | | | 204 | | | | 205 | | Person | | 206 | | | | 207 | | |\ | 208 | / +----------------+ \ | 209 | / | \ | 210 | / | \ | 211 | / | \ | 212 | / | \ | 213 | / | \ | 214 | / | \ | 215 | V V V | 216 | +----------------+ +----------------+ +----------------+ | 217 | | | | | | | | 218 | | | | | | | | 219 | | Service | | Service | | Service | | 220 | | | | | | | | 221 | | | | | | | | 222 | +----------------+ +----------------+ +----------------+ | 223 | \ / \ | 224 | \ / \ | 225 | \ / \ | 226 | \ / \ | 227 | V V V | 228 | +----------------+ +----------------+ | 229 | | | | | | 230 | | | | | | 231 | | Device | | Device | | 232 | | | | | | 233 | | | | | | 234 | +----------------+ +----------------+ | 235 | | 236 | | 237 | | 238 | Presentity (URI) | 239 +--------------------------------------------------------------------+ 241 Figure 1 243 The data model for presence is shown in Figure 1. The model seeks to 244 describe the presentity, which is identified by a URI, called the 245 presentity URI. There are three elements in the model. They are the 246 person, the service, and the device. Each of these data elements 247 contains information (called attributes) that provide a description 248 about the service, person, or device. It is central to this model 249 that each attribute is affilitated with the service, person, or 250 device because they describe that service, presentity or device. 251 This is in contrast to a model whereby the attributes are associated 252 with the service, presentity, or device because they were reported by 253 that service, presentity, or device. As an example, if a cell phone 254 reports that a user is in a meeting, this would be done by including 255 an attribute as part of the person information, indicating a status 256 of "in-a-meeting". The presence information may also include 257 information on the cell phone as a device. However, even though it 258 is that device which is reporting that the user is in a meeting, the 259 busy indicator is not associated with the device, it is associated 260 with the user. 262 The identifier for the presentity is a URI. For each unique 263 presentity in the network, there is a unique URI. This URI is 264 independent of any of the services or devices that they possess. 265 However, the URI is not just a name - it represents a resource that 266 can be subscribed to, in order to find out the status of the user. 267 As such, it can either be a SIP URI for the user, to which SUBSCRIBE 268 requests can be directed, or else it can be a pres URI [10]. When 269 the URI is a SIP URI, it will often be the address-of-record for the 270 user, to which SIP calls can be directed. This equivalence is not 271 mandated by this specification, but is a recommended configuration 272 for easing the burden of remembering and storing identifiers for 273 users. 275 3.1 Person 277 The person data element models information about the user whom the 278 presence data is trying to describe. This information consists of 279 characteristics of the user, and their status. 281 Characteristics of a person are the static information about a user 282 that does not change under normal circumstances. Such information 283 might include physical characteristics, such as age and height. 284 Status information about a presentity represent the dynamic 285 information about a user. These typically are things the *user* is 286 doing, places the *user* is at, feelings the *user* has, and so on. 287 Examples of typical person status are "in a meeting", "on the phone", 288 "out to lunch", "happy" and "writing Internet Drafts". The line 289 between static status information and dynamic status information is 290 fuzzy, and it is not important that a line be drawn. The model does 291 not differentiate in a meaningful way between these two types of 292 attributes. 294 In the model, there can only be one person element per presentity. 295 It is possible for the person data element to model "users" that are 296 in fact multiple people, for example, a customer support desk. 297 Nothing in the model mandates that the entity being modeled is 298 actually composed of a single user. This specification only mandates 299 that the result of the modeling activity be a single person data 300 element, which appears to a consumer of the document to be a single 301 user. 303 3.2 Service 305 Each presentity has access to a number of services. Each of these 306 represent a form of communications that can be used to interact with 307 the user. Examples of services are telephony (that is, traditional 308 circuit-based telephone service), push-to-talk, instant messaging, 309 Short Message Service (SMS), and Multimedia Message Service (MMS). 310 When a service is accessible over a communications network, it is 311 represented with a URI that can be "hit" in order to access the 312 service. However, some services are not accessible over a 313 communications network (such as in-person communications or a written 314 letter), and as such, may not utilize a URI. 316 Each service is adorned with characteristics that describe the nature 317 of the service that will be experienced when a watcher invokes that 318 URI. Examples of such characteristics are the type of media that 319 might be used, the directionality of communications that are 320 permitted, the quality of the service, and so on. These 321 characteristics are important when multiple services are indicated. 322 That is because the purpose of listing multiple services in a 323 presence document is to give the watcher a *choice*. That is, the 324 presentity is explicitly offering the watcher an opportunity to 325 contact them using a multiplicity of different services. To help the 326 watcher make a decision, the presence document includes 327 characteristics of each service which help differentiate the services 328 from each other, and give the watcher the context in which to make a 329 choice. 331 In this model, services are not explicitly enumerated. That is, 332 there is no "service" attribute with values of "ptt" or "telephony". 333 Rather, the service is identified in one of two ways. In many cases, 334 the URI scheme is a clear indicator of service. An "sms" URI [19] 335 clearly indicates SMS, and a "tel" URI [22] clearly indicates 336 telephony [[OPEN ISSUE: Does the tel URI really indicate 337 telephony??]]. For some URIs, there may be many services available, 338 for example, SIP. For those services, each service has a set of 339 characteristics, each of which has a well-defined meaning, such that 340 a system can unequivocally determine whether or not the service has 341 that characteristic. This is discussed in more detail in [7]. 342 [[OPEN ISSUE: What attributes do we use to determine that the service 343 is in-person communications or written communications?]] [[OPEN 344 ISSUE: Do we fold roach-simple-service-features into this document?]] 346 One important characteristic of each service is the list of devices 347 on which that service executes. Each device is identified uniquely 348 by a device ID. As such, the service characteristics can include a 349 list of device IDs. A presence document might also contain a 350 information on each device, but this is a separate part of the 351 document. Indeed, the information on each device might not even be 352 present in the document. In that case, the device IDs listed for 353 each service are nothing more than correlation identifiers, useful 354 for determining when two services run on the same device. The 355 benefit of this model is that information on the devices can be 356 filtered out of a presence document, yet the service information, 357 which includes the device IDs, remains useful and meaningful. 359 It is perfectly valid for a presence document to contain just a 360 single service. This is permitted even if the presentity actually 361 has multiple services at their disposal. The lack of multiple 362 services in the document merely means that the presentity is not 363 offering a choice to the watcher. In such a case, the service 364 characteristics are less important, but may be helpful in allowing a 365 watcher to decide if they wish to communicate at all. 367 The URI is an important part of the service. When the watcher makes 368 a decision about which service of the presentity they wish to access, 369 the watcher invokes the URI associated with that service. It is not 370 necessary for the watcher to add additional information to a message 371 generated by invoking that URI in order to reach the service 372 described in the document. Specifically, it is not necessary for a 373 watcher to add SIP caller preferences [14] in order to request 374 routing of the request to a service with the characteristics 375 described in the document. As a result, each service in the presence 376 document will have a different URI. 378 The URI represents a weak form of contract; the presentity tells the 379 watcher that, if the watcher invokes the URI as included in the 380 presence document, the watcher might be connected to a service 381 described by the characteristics included in the presence document. 382 It is important to stress that this is not a guarantee in any way. 383 It cannot be a guarantee for two reasons. Firstly, the service in 384 the document might actually be modelling a number of actual services 385 used by the user, and it may not be possible to connect the watcher 386 to a service with all of the characteristics described in the 387 presence document. Secondly, the preferences of the presentity 388 always take precedence. The caller might ask to be connected to the 389 video service, but it is permissible to connect them to a different 390 service if that is the wish of the presentity. 392 The URI also plays another important role - it acts as the unique 393 identifier for the service. When two presence user agents publish 394 information about a service, the service URI is what indicates that 395 the service information they are publishing is for the same or 396 different services. For this reason, it is important that each PUA 397 use unique service URIs, and that these service URIs also be 398 persistent over time. These properties are readily met by using the 399 Globally Routable User Agent URI (GRUU) [11] as the service URI. 400 This is discussed further below. 402 Each service is also associated with a priority, which represents the 403 preference that the user has for usage of one service over another. 404 This does not mean that, when a watcher wishes to communicate with 405 the presentity, that they should always use the service with the 406 highest priority. If that were the case, there would be no point in 407 including multiple services in the presence document. Rather, the 408 priority says, "If you, the watcher, cannot decide which of these to 409 use, or if it is not important to you, this is the order in which I 410 would like you to contact me. However, I am giving you a choice." 411 The priorities are relative to each other, and have no meaning as 412 absolute numbers. If there are two services, and they have 413 priorities of 1 and .5 respectively, this is identical to giving them 414 priorities of .2 and .1 respectively. 416 Each service also has a status. Status represents dynamic 417 information about the availability of communications using that 418 service. This is in constrast to characteristics, which describe 419 fairly static properties of the various services. The simplest form 420 of status is the basic status, which is a binary indicator of 421 availability for communications using that service. Other status 422 information might indicate more details on why the service is 423 available or unavailable. For example, a telephony service might 424 have additional status to indicate that the user is on the phone, or 425 that the user is handling 3 calls for that service. 427 Services inherently have a lot of dyanmic state associated with them. 428 For example, consider a wireless telephony service (i.e., a cell 429 phone). There are many dynamic statuses of this service - whether or 430 not the phone is registered, whether or not its roaming, which 431 provider it has roamed into, its signal strength, how many calls it 432 has, what the state of those calls are, how long the user has been in 433 a call, and so on. As another example, consider an IM service. The 434 statuses in this service include whether or not the user is 435 registered, how long they have been registered, whether they have an 436 IM conversation in progress, how many IM conversations are in 437 progress, whether the user is typing, to whom they are typing, and so 438 on. 440 However, not all of this dynamic state is appropriate to include 441 within a service data element of a presence document. Information is 442 included only when it has a bearing on helping the watcher decide 443 whether or not to initiate communications with that service, or 444 helping them decide when to initiate it, if not now. As an example, 445 whether a cell phone has roamed or not does not pass this litmus 446 test. Knowing this is not likely to have an impact on a decision to 447 use this service. 449 3.3 Device 451 Devices model the physical operating environment in which services 452 execute. Examples of devices include cell phones, PCs, laptops, 453 PDAs, consumer telephones, enterprise PBX extensions, and operator 454 dispatch consoles. 456 The mapping of services to devices are many to many. A single 457 service can execute in multiple devices. Consider a SIP telephony 458 service. Two SIP phones can register against a single 459 address-of-record for this service. As a result, the SIP service is 460 associated with two devices. Similarly, a single device can support 461 a multiplicity of services. A cell phone can support a SIP telephony 462 service, an SMS service, and an MMS service. Similarly, a PC can 463 support a SIP telephony service and a SIP videophone service. 465 Devices are identified with a device ID. A device ID is a URI that 466 is a globally and temporally unique identifier for the device. In 467 particular, a device ID is a URN. The URN has to be unique across 468 all other devices for a particular presentity. However, it is also 469 highly desirable that it be persistent across time, globally unique, 470 and computable in a fashion so that different systems are likely to 471 refer to the device using the same ID. With these properties, 472 differing sources of presence information based on device status can 473 be combined together. 475 Unfortunately, due to the variety of different devices in existence, 476 it is difficult for a single URN scheme to be used. For those 477 devices that already make use of MAC addresses as a unique 478 identifier, the UUID URN [20] makes a good choice. It is expected 479 that, in the future, other URN schemes will be defined that are 480 meaningful for other device types. [[OPEN ISSUE: On more detailed 481 read, it seems that if the UUID URN is based on MAC, it also includes 482 a time-based random part, which would make it less useful for the 483 requirements here. We may need a MAC URN.]] 485 Though this document does not mandate a particular implementation 486 approach, the device ID is most useful when all of the services on 487 the device have a way to obtain the device ID, and get the same value 488 for it. This would argue for its placement as an operating system 489 feature, and operating system developers interested in implementing 490 this specification are encouraged to provide APIs that allow 491 applications to obtain the device ID. Absent such APIs, applications 492 which report presence information about their devices will have to 493 generate their own device IDs. This leads to the possibility that 494 the applications may choose different device IDs, using different 495 algorithms or data. In the worst case, these may mean that two 496 services which run on the same device, do not appear to. 498 Like services and person data elements, device data elements have 499 static characteristics and dynamic status. Characteristics of a 500 device include its physical dimensions and capabilities - the size of 501 its display, the speed of its CPU, and the amount of memory. Status 502 information includes dynamic information about the device. This 503 includes whether or not the device is powered on or off, the amount 504 of battery power that remains in the device, the geographic location 505 of the device, and so on. 507 The characteristics and status information reported about a device 508 are for the purposes of choice - to allow the user to choose the 509 service based on knowledge of what the device is. The device 510 characteristics and status cannot, in any reliable way, be used to 511 extract information about the nature of the service that will be 512 received on the device. For example, if the device characteristics 513 include the speed of the CPU, and the speed is sufficient to support 514 high quality video compression, this cannot be interpreted to mean 515 that video quality would be good for a video service on that device. 516 Other constraints on the system may reduce the amount of CPU 517 available to that service. If there is a desire to indicate that 518 higher quality video is available on a device, that should be done by 519 including service characteristics that say just that. The speed of 520 the CPU might be useful in helping the watcher differentiate between 521 a device that is a PC and one that is a cell phone, in the case where 522 the watcher wishes to call the user's cell phone. 524 Similarly, if there is dynamic device status (such as whether the 525 device is on or off), and this state impacts the state of the 526 service, this is represented by adjusting the state of the service. 527 Unless a consumer of a presence document has apriori knowledge 528 indicating otherwise (note that presence agents often do), the state 529 of a device has no bearing on the state of the service. 531 Just like services, there is no enumeration of device types - PCs, 532 PDAs, cell phones, etc. Rather, the device is defined by its 533 characteristics, from which a watcher can extrapolate whether the 534 device is a PDA, cell phone, or what have you. 536 It is important to point out that the device is a *model* if the 537 underlying physical systems in which services execute. There is 538 nothing that says that this model cannot be used to talk about 539 systems where services run in virtualized systems, rather than real 540 ones. For example, if a PC is executing a virtual machine, and 541 running services within that virtual machine, it is perfectly 542 acceptable to use this model to talk about that PC as being composed 543 of two separate devices. 545 4. Motivation for the Model 547 Presence is defined in [5] as the ability, willingness or desire to 548 communicate across a set of devices. The core of this definition is 549 the conveyance of information about the ability, willingness or 550 desire for communications. Thus, the presence data model needs to be 551 tailored around conveying information that achieves this goal. 553 The person data element is targeted at conveying willingness and 554 desire for communications. It is used to represent information about 555 the user themselves that affects willingness and desire to 556 communicate. Whether or not I am in a meeting, whether or not I am 557 on the phone - each of these says something about my willingness to 558 communicate, and thus makes sense for inclusion in a presence 559 document. 561 The service component of the data model aims to convey information on 562 the ability to communicate. The ability to communicate is defined by 563 the services by which a user is reachable. Thus, including them is 564 essential. 566 How do devices fit in? For many users, devices represent the ability 567 to communicate, not services. Frequently, users my statements like, 568 "call me on my cell phone" or, "I'm at my desk". These are 569 statements for preference for communications using a specific device, 570 as opposed to a service. Thus, it is our expectation that users will 571 want to represent devices as part of the presence data. 573 Furthermore, the concept of device adds the ability to correlate 574 services together. The device models the underlying platform that 575 supports all of the services on the phone. Its state therefore 576 impacts all services. For example, if a presence server can 577 determine that a cell phone is off, this says something about the 578 services that run on that device - they are all not available. Thus, 579 if services include indicators about the devices on which they run, 580 device state can be obtained and thus used to compute the state of 581 the services on the device. 583 The data model tries hard to separate device, service, and person as 584 different concepts. Part of this differentiation is that many 585 attributes will be applicable to some of these, but not others. For 586 example, geographic location is a meaningful attribute of the person 587 (the user has a location) and of a device (the device has a 588 location), but not of a service (services don't inherently have 589 locations). Based on this, geographic location information should 590 only appear as part of device or person, never service. Furthermore, 591 it is possible and meaningful for location information to be conveyed 592 for both device and person, and for these locations to be different. 593 The fact that the presence system might try to determine the location 594 of the person by extrapolation from the location of one of the 595 devices is irrelevant from a data modeling perspective. Person 596 location and device location are not the same thing. 598 5. Encoding 600 Information represented according to the data model described above 601 needs to be mapped into an on-the-wire format for transport and 602 storage. The Presence Information Document Format [3] is used for 603 representation of presence data. 605 The element contains the presence information for the 606 presentity. The "entity" attribute of this element contains the 607 presentity URI. 609 The existing element in the PIDF document is used to 610 represent the service. This is consistent with the original intent 611 of RFC 2778 and RFC 3863, and achieves backwards compatibility with 612 implementations developed before the model described here was 613 complete. The element in the element is used to 614 encode the service URI. Presence attributes representing dynamic 615 status appear as children to the element, and attributes 616 representing static characteristics appear directly as children of 617 . It is not critical that a clean separation between dynamic 618 and static information be made. It is only important that each 619 presence attribute be specified to appear in either or 620 . 622 This specification introduces the element, which can appear 623 as a child to . There can only be one instance of this 624 element per document. It contains any number of child elements that 625 indicate characteristic information, followed by the 626 element, which contains any number of elements containing dynamic 627 status information. 629 This specification also introduces the element, which can 630 appear as a child to . There can be zero or more instances 631 of this element per document. Each one has a mandatory "device-id" 632 attribute which contains the URN for the device ID. Like , 633 it contains any number of elements containing characteristic 634 information, followed by the element, which contains any 635 number of elements containing dynamic status information. 637 A client that receives a PIDF document containing the and 638 elements will ignore them. Furthermore, since the semantics 639 of service as defined here are aligned with the meaning of a tuple as 640 defined in RFC 2778 and RFC 3863, documents incorporating the 641 concepts defined in this model are compliant with older 642 implementations. 644 It's important to note that the mapping of the presence data model 645 into a PIDF document is merely an exercise in syntax. 647 5.1 XML Schema 649 5.1.1 Person 651 652 656 657 658 Abstract type for characteristics 659 for person 660 661 662 663 664 Abstract type for status for person 665 666 667 669 670 Person characteristic 671 element (abstract) 672 673 674 675 676 Person status element (abstract) 677 678 679 680 681 Contains information 682 about the human user 683 684 685 686 688 689 690 691 692 693 694 695 696 697 698 700 5.1.2 Device 702 703 707 708 709 Abstract type for characteristics for 710 device 711 712 713 714 715 Abstract type for status for device 716 717 718 720 721 Device characteristic element 722 (abstract) 723 724 725 726 727 Device status element (abstract) 728 729 730 731 732 Contains information about the device 733 734 735 736 738 739 740 741 742 743 744 745 746 747 748 749 751 6. Publication 753 Publication is defined as the process by which an event publication 754 agent (EPA) pushes event state into the network [12]. In this 755 section, we consider how an EPA for the presence event package would 756 generate the presence document it will publish. 758 6.1 Reporting 760 Reporting is the process whereby a service publishes about itself, an 761 agent on a device publishes about the device, or an agent 762 representing the human user publishes person information elements. 763 Reporting is in contrast to overriding, where a software agent 764 attempts to publish information about a different service or device. 766 An EPA for presence (also known as a Presence User Agent (PUA)) 767 computes the presence document as if it had full knowledge of the 768 state of the presentity. That is, it represents the complete view of 769 user presence as understood by that PUA. Frequently, the PUA is a 770 software agent that acts as a service, and will therefore be 771 authoritative for the service information it reports. It is 772 anticipated that services will also frequently report information on 773 device and person status as well, as this information is sometimes 774 collected by applications representing services. It is possible that 775 devices can themselves publish information about a presentity, and 776 that software agents representing the person, and not their services, 777 can also publish presence documents. For the remainder of this 778 discussion, we assume that the entity doing the publishing is a 779 service. 781 When a document is created by such a PUA, the presentity URI (encoded 782 in the "entity" attribute) will typically be a SIP URI, and equal to 783 the AOR of the presentity. This will also usually be the same as the 784 request URI in the PUBLISH request itself, but it need not be so. 785 The URI serve different purposes. As described in [12], the request 786 URI serves as a means to route the request to the appropriate event 787 state compositor, and identity the target of the publication. As 788 such, it is primary a means for targeting the document. The entity 789 about whom presence is reported is always taken from the "entity" of 790 the presence document. 792 A PUA will also publish the services it knows about, and the device 793 it's associated with. The service URI needs to be a unique 794 identifier that defines the service as far as the PUA is concerned. 795 That URI should be a GRUU, as discussed above. The device ID for the 796 device is obtained from the local operating system. 798 6.2 Overriding 800 Overriding is the process whereby a PUA attempts to publish 801 information in an explicit attempt to have that information take the 802 place of information published by a different PUA for the same 803 presentity. 805 The motivating use case for this feature is as follows. A user has 806 an office PC and a home PC, both of which run an Instant Messaging 807 (IM) application. While at work, they set the status of their IM 808 application to "in a meeting". This information is reported in 809 publications produced by the PUA on their office PC. When the user 810 arrives at home, they realize that their office PC is still reporting 811 out-of-date information, and they would like to correct it. As such, 812 the user would like their home PC to publish data that overrides the 813 information being published by their office PC. 815 In this specific example, the office PC will be publishing a document 816 with a person information element indicating that the user is in a 817 meeting and a service information element indicating availability for 818 IM communications. The service URI is equal to the GRUU for that 819 client. The home PC will be publishing a document with a person 820 information element indicating that the user is at home and a service 821 information element indicating availability for IM service. That IM 822 service uses a different service URI than the one at work, since the 823 two are running on separate UA instances. This presents the presence 824 server with conflicting person information elements for the same 825 presentity. 827 Overriding is ultimately an attempt by a publisher to force the 828 composition processing in a presence server to resolve a conflict in 829 a particular way. Ideally, this is done by having a software agent 830 directly set the composition policy that will be used, and then 831 publishing information which will be known to "win" the conflict 832 resolution. In the absence of directly controllable conflict 833 resolution policies, Section 7.2.2 provides guidelines on resolving 834 conflicts for service, device and person information. Publishers can 835 attempt to make use of these guidelines to cause an override to 836 occur. 838 In most cases, the information that needs to be overriden will be 839 person information. In the example above, the stale information is 840 the status "in a meeting", which is a property of the person 841 information element. Service information is most usually "self 842 reported" - that is, reported by an agent providing that service. 843 That agent will likely be authoritative for the service, and it is 844 unlikely that some other service needs to provide more up to date 845 information. The situation is more complicated for devices. At the 846 time of writing, most devices did not contain separate agents that 847 published information about themselves; the publication happens from 848 the software agent providing the service. This does present the 849 possibility that conflicting or incorrect information could be 850 reported about a device, neccesitating an override. Since a human 851 being is authoritative about the person information elements, it is 852 likely that any software agent that reports it will have incorrect 853 information. It is for this reason that person information elements 854 are expected to be the most common target for overrides. 856 Fortunately, overriding person information is easy. The guidelines 857 in Section 7.2.2 recommend that, absent policy or meta-data guiding 858 otherwise, the most recently reported status wins. An agent wishing 859 to override the person status can therefore just publish a person 860 information element for the presentity. It only needs the presentity 861 URI to do so. 863 Overriding service and device information elements is more 864 complicated, since it requires the service URI or device ID published 865 by that service or device. The composition operation will often 866 modify the service URI and device ID before the presence document is 867 distributed to watchers. The result is that a normal watcher of 868 presence information will not have enough information at its disposal 869 to perform an override. At the time of writing, it was anticipated 870 that new event packages could be defined to facilitate this 871 discovery, should the need really arise in practice. 873 7. Presence Server Processing 875 In this section, we outline the processing a server does on presence 876 documents. The basic flow of operations is shown in Figure 4. 878 +---------+ 879 |Presence | 880 | Source |\ 881 +---------+ \ +-----------+ 882 \ | | 883 \ /------\ | Raw | //------\\ 884 +---------+ \// Create \\ | Presence | || Privacy ||-----+ 885 |Presence |----| View |-->| Document |->|| Filtering|| | 886 | Source | \\ // | | \\------// | 887 +---------+ / \------/ | | | 888 / ^ +-----------+ ^ | 889 / | | | 890 +---------+ / +------------+ +------------+ | 891 |Presence |/ | Composition| | Presence | | 892 | Source | | Policy | | Auth | | 893 +---------+ | | | | | 894 | | | | | 895 +--------| | | | | 896 | +------------+ +------------+ | 897 | | 898 V V 899 ------ +-----------+ +-----------+ 900 //// \\\\ | | ------ | | 901 | Post | | Filtered | /// \\\ | Candidate | 902 | Processing |<---| Presence |<--| Watcher | | Presence | 903 | Composition | | Document | | Filter | <---| Document | 904 \\\\ //// | | \\\ /// | | 905 ------ | | ------ | | 906 | +-----------+ +-----------+ 907 | 908 | 909 | 910 | 911 V 913 +-----------+ 914 | | 915 | Final | 916 | Presence | 917 | Document | 918 | | 919 | | 920 +-----------+ 922 Figure 4 924 7.1 Collection 926 The first step is the process of collection. Collection is defined 927 as the process of obtaining the set of event state that is necessary 928 for performing the composition operation that creates the initial 929 view. A view is defined as the particular stream of presence 930 documents seen by a watcher after the application of policy. In this 931 case, the initial view is the view of the presentity before the 932 application of privacy and watcher filtering. 934 The event state that is collected includes all of the presence 935 documents that have been published for the presentity. This, by 936 definition, is the set of documents whose "entity" attribute in the 937 element in the presence document is the same as that of 938 the presentity. However, it may also include other presence 939 documents for other presentities, in cases where the presence server 940 knows that the state of one presentity is a function of the state of 941 another. An example is the helpdesk presentity, whose state is a 942 function of the state of the users in the help desk. 944 In addition to presence events, other event state can be used as 945 well. As an example, registration state [2] has a bearing on 946 presence, as does dialog state [21], and the state of non-SIP 947 systems, such as traditional telephony equipment, layer 2 devices, 948 and so on. This state can be obtained by a presence server in 949 several ways. Firstly, publishers for that state can send PUBLISH 950 requests for it to the presence server. In another approach, the 951 presence server acts as a watcher, and subscribes to the event state 952 for the resources it needs. This is referred to as a back-end 953 subscription. 955 Each of these non-presence events can then be converted into a piece 956 of presence state (presentity, device or service information) based 957 on local policy. For example, if the presence server has somehow 958 obtained information that says that the user's cell-phone is on, this 959 can be converted into device state (using the device ID of the phone) 960 along with service state, if the presence server knows about the 961 services on the device. 963 Registration state is of particular importance. It can be obtained 964 by a presence server by having the presence server co-located with 965 the registrar, or by having the presence server subscribe to the 966 registration event package for the user [2]. Each registered contact 967 is considered a service. The service URI (expressed in the 968 element in each tuple of the presence document) is obtained from the 969 GRUU for each contact, if it exists, else it is set to the Contact 970 URI from the registration. Service parameters can be extracted from 971 any callee capabilities provided in the registration [13]. The 972 presentity URI is set to the address-of-record. This mapping has the 973 advantage that it is readily correlated to any service information 974 that might also be PUBLISHed explicitly by that UA. As such, a UA 975 that registers should also PUBLISH its state, in the event the 976 presence server cannot access registration information. 978 Once the non-presence event state is converted into pieces of 979 presence state, the compositor will have, at its disposal, a set of 980 presence data, each of which is for the same presentity. 982 7.2 Composition 984 The next step in the process is the composition operation, which 985 produces the raw presence document, also known as the initial view, 986 from the document sources. This document is "raw" because it 987 contains more information than any watcher might actually see. 988 Privacy and watcher filtering may eliminate some of the data from the 989 document. 991 The means by which composition is done is a matter of local policy. 992 However, there are some general tools and techniques that merit 993 discussion. 995 7.2.1 Correlation 997 A key part of composition is using information in one presence 998 document, describing a person, service or device, to affect 999 information in another. As an example, if the presence server has a 1000 document indicating that the user has a telephony service that is 1001 busy, the server can use this to extract information about the person 1002 - that they are on the phone. Similarly, if one document indicates 1003 that a device with ID 1 is off, and another document that indicates a 1004 telephony service is running on the device with ID 1, the server can 1005 determine that the telephony service is closed. 1007 The way in which the various input data impact each other are a 1008 matter of local policy. However, a key to performing such 1009 combination operations is the usage of a correlation identifier that 1010 can match a service, device, and person together across input 1011 sources. The presence document provides the service URI, presentity 1012 URI and device ID as correlation identifiers. All three of these 1013 identifiers have uniqueness and temporal persistence properties that 1014 make them useful for purposes of correlation. Indeed, its not just 1015 that the identifiers have temporal persistence; its that they have a 1016 common value that is used persistently across different sources. In 1017 the example above, the device ID of 1 is useful for correlating the 1018 device state to the service state, if, and only if, the source 1019 indicating the device state uses the same device ID as the source 1020 indicating the service state. This makes selection of the device ID 1021 a critically important operation. 1023 7.2.2 Conflict Resolution 1025 In some cases, there may be multiple sources that provide conflicting 1026 information about a service, person, or device. In this case, 1027 "conflicting" means that there are multiple person data elements that 1028 say different things, multiple service data elements for the same 1029 service (where the same service is defined as two services with the 1030 same service URI), or multiple device data elements with the same 1031 device ID. 1033 Conflicting person information is very likely. The typical situation 1034 is described in Section 6.2, where a user wishes to change a stale 1035 status set by another software agent no longer under their direct 1036 control. 1038 Ultimately, how to resolve conflicts is under the control of the 1039 composition policy governing the operation of the server. Here, we 1040 discuss approaches that would be typical and appropriate to use. 1042 One way in which conflicts can be resolved is by measuring the 1043 likelihood that the information from each source is accurate. In 1044 this simple case, the person data element is reported from two IM 1045 clients. However, one IM client may report an idle indicator for the 1046 device, whilst the other (the home IM client) reports that it is not 1047 idle. The presence server can use this information to believe the 1048 device which is not idle. 1050 More generally, when a source publishes information, it publishes its 1051 "world view", including information it thinks it knows about the 1052 person, about the service it is providing, and the device it runs on. 1053 The fact that all of these are reported together in a presence 1054 document is key. It provides additional context that can be used to 1055 determine the level of accuracy of a source for particular 1056 information. For example, if a cell phone reports that the user is 1057 in a meeting, the cell phone's document will include, in addition to 1058 the person status, cell phone device and cell phone service 1059 information. Simimlarly, if a calendaring application acts as a 1060 source, and indicates that the user is in a meeting, it would include 1061 only information about the meeting. The presence server might decide 1062 to trust the information that reports *just* the meeting, more than a 1063 cell phone that reports a meeting. 1065 The presence server may also know the source of the presence data, 1066 based on authenticated identities. For example, in the case above, 1067 the calendaring application may have a separate identity it uses to 1068 authenticate itself to the presence server. The presence server can 1069 be configured to know that the owner of that particular authenticated 1070 identity is a calendar application, and therefore, it can trust its 1071 information on meeting status information more than another source. 1072 [[OPEN ISSUE: do we want a attribute that can be used to 1073 explicitly define information about the publisher of the 1074 information?? How would this be authorized??]]. 1076 Without such additional meta-data, the conflict can be resolved by a 1077 simple freshness metric. The presence source which has most recently 1078 begun reporting information for a specific service, device or person 1079 data element, wins. It is imporant not to confuse the time at which 1080 a status is initially reported, from when it is refreshed. The 1081 former occurs when the status of the person, device or service 1082 changes, and the latter occurs for subsequent publications which do 1083 not change the value. 1085 Conflicts of services or devices are less likely to occur in the 1086 model presented here, due to the unique nature of the service URI and 1087 device ID. However, it is possible. Indeed, a client might 1088 explicitly choose to publish with the same service URI as another 1089 client, if its goal is to explicitly override the service of the 1090 other. Using the same service ID is the "hint" to the presence 1091 server that conflicting data exists, and one needs to be chosen. 1093 7.2.3 Merging 1095 Merging is an operation that allows a presence server to combine 1096 together a set of different services or devices into a single 1097 composite service or device. Two services are different if they have 1098 different service URIs, and two devices are different if they have 1099 different device IDs. This operation is a common one in composition 1100 operations. 1102 The merging process involves three steps. The first is to select the 1103 set of services or devices to merge. The second is to combine the 1104 characteristics and status of each. The third is to generate a 1105 composite service URI or device ID. 1107 One way to identify the set of services that will be combined is by 1108 defining a "pivot". A pivot is a particular attribute (either 1109 characteristic or status) of a service that is used as the selector. 1110 All of the services in the raw presence document for whom the pivot 1111 attribute has the same value, are all combined together, and the 1112 resulting service will clearly have that value for that particular 1113 pivot attribute. If the raw presence document has three distinct 1114 values for the pivot attribute, the presence document, after 1115 combination, will have three services. 1117 For example, if the video prescaps [15] attribute is used as the 1118 pivot, then all services that support video will be combined, and all 1119 of those that don't will be combined. The resulting presence 1120 document after merging will have two services - one with a 1121 characteristic of video, and one with a characteristic of no-video. 1123 An important pivot is the SIP address-of-record. When a PUA 1124 publishes a presence document, it includes its GRUU as the service 1125 URI in the element in the tuple. If the presence server 1126 has access to registrar data, it can determine the AOR associated 1127 with that GRUU (if there is one). By using the implicitly provided 1128 AOR as a pivot, the presence server can combine together all of the 1129 services which are reachable through the same AOR. 1131 Once the set of services or devices is selected, the next step is to 1132 combine their characteristics and status information. How the 1133 characteristics and status are combined will vary for each attribute. 1134 For many attributes, if the value is the same across all services, 1135 the combination operation is easy - use that value. If the attribute 1136 differs across services, it is a matter of local policy as to how 1137 they are combined. 1139 As an example, consider the status as defined in [3]. The 1140 most sensible combination operation is the boolean OR operation. 1141 That is, a composite service is said to be available as long as one 1142 of its component services is available. 1144 The final step, combining service URIs, is more complicated. If the 1145 service URIs are GRUUs within the same AOR, they can easily be 1146 combined by using the AOR as the result of the combination function. 1147 Indeed, even if the presence server is not combining multiple 1148 services together, it might make sense to change the GRUU to the AOR 1149 in the presence document delivered to a watcher. If the service URIs 1150 are SIP URIs but are not GRUUs, the presence server may need to 1151 create a URI which represents the collection of services. Requests 1152 made to that URI could fork to the set of services that were combined 1153 together. If the service URIs are not even the same URI scheme, for 1154 example, a mailto and a tel URI, there is little that can be done. 1155 In such a case, the URI should be removed from the 1156 document. There are some cases where URIs with distinct URI schemes 1157 can be combined. For example, if one service has a tel URI, and the 1158 other has a SIP URI, a combined service can be represented by a SIP 1159 URI generated by the presence server. If the watcher generates a 1160 request towards this SIP URI, the proxy server could fork the request 1161 to the original tel URI and the original SIP URI. This works in this 1162 specific case (sip and tel URI combination) because SIP requests can 1163 sensibly be directed to a tel URI. These cases aside, it is 1164 generally not a good idea to combine services together that have 1165 radically different URIs. 1167 The merging operation takes place for devices identically to the way 1168 it takes place for services. Fortunately, combining of device IDs is 1169 a bit less complicated than combining service URIs. The server can 1170 manufacture new device IDs that represent a "virtual" device that 1171 represents a collection of other devices. 1173 It is perfectly valid for the merging operation to eliminate all 1174 devices from the final document, or to eliminate the person data 1175 element. However, for a presence document to be meaningful, it has 1176 to contain at least one service data element (encoded using a 1177 ). 1179 If a presence document is obtained by using the device ID within each 1180 service element as a pivot, the result is a device view - there is a 1181 single service in the document for each device. If all of the 1182 services are composed together, so that the final document has a 1183 single service, it is called a presentity view. A service view is 1184 used to describe documents where services are either uncombined, or 1185 are combined using a pivot other than the device ID. 1187 7.2.4 Splitting 1189 Splitting is the process of taking a single service or device data 1190 element, and splitting into two services or devices. This is useful 1191 when the presence server or presence user agent wishes to model a 1192 complex application (such as a voice, video and IM enabled client) by 1193 a multiplicity of distinct services. 1195 The process of splitting involves taking the attributes (both status 1196 and characteristics) for the service, and determine which of the 1197 component services that attribute will describe. In some cases, a 1198 single attribute will be split so that it is present in both 1199 components. For example, if the composite service has an idle 1200 indication, meaning that the service has not been used in some time, 1201 the component services would both inherit the same value for the idle 1202 indicator. In other cases, an attribute gets assigned only to one 1203 service, or in other cases, its value is changed as it is split up. 1204 The way in which this is done is a matter of local policy. 1206 In all cases, it is important to remember that the purpose of having 1207 multiple services or devices described in a document is to give the 1208 watcher choice about what service to use. Therefore, the splitting 1209 operation should result in multiple services that have sufficient 1210 characteristics associated with them to differentiate them to a 1211 watcher. 1213 Splitting of a service URI is a relatively simple operation. The 1214 entity performing the split creates two new service URIs, each of 1215 which, should a request be received for that URI, would get 1216 translated to, or routed to, the composite service URI. If a 1217 presence user agent is performing the split, it can use the grid 1218 parameter of the GRUU to manufacture an infinite supply of URIs that 1219 all get routed to itself. If a presence server is doing the split, 1220 it can manufacture an entirely new URI (in conjunction with the 1221 domain owner, of course) as needed. 1223 When a service is split, there is usually no reason to split the 1224 device as well. The component services all run on the same device, 1225 and there is much benefit to indicating that this is the case. For 1226 example, it would allow a presence server that is compositing the 1227 presence document for the presentity, to determine that all of the 1228 component services are inactive if the device should fail. 1230 7.3 Privacy Filtering 1232 Once the merging operation has been applied, the next step is to 1233 perform privacy filtering. Privacy filtering is a process by which 1234 information is removed or transformed in a raw presence document, for 1235 the purposes of withholding sensitive information about the 1236 presentity. Typically, the filtering operation runs at the bequest 1237 of the presentity, in order to protect their own privacy. However, 1238 privacy filtering can be instantiated by the operator, in order to 1239 execute domain filtering policies, or even third parties that are 1240 authorized to specify filtering. 1242 The exact privacy filtering operation that takes place depends on the 1243 identity of the watcher, and can also depend on other variables, such 1244 as time of day, the weather in Helsinki, and so on. The set of 1245 information that dictates the way in which privacy filtering is 1246 executed is called authorization policy. 1248 Authorization policy is expressed using the document format defined 1249 in [9]. 1251 7.4 Watcher Filtering 1253 Watcher filtering is the process by which information is further 1254 removed from the presence document. However, it is the watcher which 1255 specifies the information subset that they would like to receive. 1256 Watcher filtering is accomplished by including filter documents in 1257 subscription requests. These filters are then bound to the 1258 subscription, and applied to any presence document generated during 1259 the lifetime of that subscription. 1261 Filters are described using the document format defined in [16]. 1263 7.5 Post-Processing Composition 1265 After the privacy and watcher filtering operations have been applied, 1266 the resulting presence document may contain service or device 1267 elements which no longer contain enough information to differentiate 1268 one from another. As discussed above, the purpose of having multiple 1269 services or devices described in a document is to give the watcher 1270 choice about which service to invoke. If the services defined in a 1271 document all appear the same, differing only in the service URI, 1272 there is no reason for a user to choose one over another. In such a 1273 case, composition rules, and in particular, merging of services, will 1274 need to be done. The result is the final presence document that can 1275 be delivered to watchers. 1277 8. Extending the Presence Model 1279 When new presence attributes are added, any such extension has to 1280 consider the following questions: 1281 1. Is the new attribute applicable to person, service or device data 1282 elements? If it is applicable to more than one, what is its 1283 meaning in each context? An extension should strive to have each 1284 attribute concisely defined for each area of applicability, so 1285 that a source can clearly determine to which type of data element 1286 it should be applied. 1287 2. Is this new attribute a dynamic status, or a static 1288 characteristic? Characteristics are information that describe 1289 information about devices, services or a person that help provide 1290 context for a consumer of the document to make a decision about 1291 whether communications is desired in one place or another. They 1292 are therefore descriptive in nature. 1294 9. Example Presence Documents 1296 In this section, we give examples of different physical systems, 1297 present the model of that system using the concepts described here, 1298 and then show the resulting presence document. 1300 Some of the examples and content in this section are lifted from [6]. 1302 9.1 Basic IM Client 1304 In this scenario, a provider is offering a service very similar to 1305 the instant messaging services offered today by the public providers 1306 like AOL, Yahoo, and MSN. In this service, each user has a "screen 1307 name" that identifies them in the service. A single client, 1308 generally a PC application, connects to the service at a time. When 1309 the client connects, this fact is made available to other watchers of 1310 that user in the system. The user has the ability to set a textual 1311 note that describes what they are doing, and this note is seen by the 1312 watchers in the system. The user can set one of several status 1313 messages - such as busy, in a meeting, etc., which are pre-defined 1314 notes that the system understands. If a user does not type anything 1315 on their keyboard for some time, their status changes to idle on the 1316 screens of the various watchers of the system. The system also 1317 indicates the amount of time that the user has been idle. 1319 Whenever a user is connected to the system, they are capable of 1320 receiving instant messages. A user can set their status to 1321 "invisible", which means that they appear as offline to other users. 1322 However, if an IM is sent to them, it will still be delivered. 1324 This system is modeled by representing each client in the system with 1325 three data elements - a person element, a service element, and a 1326 device element. The person element describes the state of the user, 1327 including the note and the pre-defined status messages. These 1328 represent information about the human user, so they are included in 1329 the person element. The service tuple represents the IM service. No 1330 characteristics are included. The service URI published by the 1331 client is set to the client's GRUU. The device element is used to 1332 model the PC. The device element includes the idle indicator, since 1333 the idleness refers to usage of the *device*, not the service. 1334 Inclusion of the idle indicator in a service tuple is permitted, but 1335 would imply something different - that the user hasnt used the 1336 service (i.e., has not used their IM client) in some time. [[OPEN 1337 ISSUE: Need to determine what the real meaning of idle is.]] 1339 The document published by the client would look like this: 1341 1342 1344 1345 mac:8asd7d7d70 1346 1347 1348 MESSAGE 1349 OPTIONS 1350 1351 1352 1353 open 1354 1355 sip:gruu-someone-1@example.com 1356 1357 1358 1359 1360 on-the-phone 1361 1362 1363 1364 1365 1366 1367 1368 1369 1371 It is worth commenting further on the value of having a separate 1372 device element just to convey the idle indicator. As described 1373 above, the idle indication of interest is really an indicator that 1374 the device is idle. By making that explicit, the idle indicator can 1375 be used by the presence server to affect the state of other services 1376 running on the same device. For example, let say there is a voip 1377 application running on the same device. This application reports its 1378 presence information using the example below. Since it reports that 1379 it runs on the same device, the presence server can use the status of 1380 the service to further refine the idle indicator of the device. 1381 Specifically, if the user is using their voip application, the 1382 presence server knows that the device is in use, even if the IM 1383 application reports that the device is idle. Typically, idleness is 1384 determined by lack of keyboard or mouse input, neither of which might 1385 be used during a voip call. 1387 In a more simplistic case, reporting the idle indicator as part of 1388 the device status allows that indicator to be used for other services 1389 on the same device. Taking, again, the example of the voip 1390 application on the same device, if the voip application does not 1391 report any device information, and a watcher is not provided 1392 information on the IM service, the presence document sent to the 1393 watcher can include the device status. Because of the usage of the 1394 device IDs and the device information, the presence server can 1395 correlate the device status as reported by the IM application with 1396 the voip service, and use them together. 1398 9.2 VoIP Application 1400 In this example, consider a SIP network. The user has a SIP AOR of 1401 sip:user@example.com. The user has a single SIP PC client that they 1402 run on their office machine. This is a simple SIP softphone, 1403 supporting audio only. 1405 The PC client publishes a presence document that has a single tuple, 1406 representing the service. It does not include any presentity or 1407 device elements, although it does include a device-id as part of its 1408 service characteristics. 1410 The document published by the client would look like this: 1412 1413 1415 1416 urn:mac:8asd7d7d70 1417 1418 1419 INVITE 1420 OPTIONS 1421 BYE 1422 ACK 1423 CANCEL 1424 1425 1427 1428 open 1429 1430 sip:gruu2@example.com 1431 1432 1434 9.3 Cellphone 1436 In this example, the user has a cellphone. This cellphone has an SMS 1437 client and a SIP push-to-talk client running. The phone also has a 1438 switch that allows the user to select "silent mode". This 1439 information is also used by the phone as an indicator of business. 1440 As it turns out, the SMS and PTT applications on the phone are 1441 totally separate, and each publishes its own information. Indeed, 1442 both happen to publish information about the silent mode switch. 1444 The SMS application models itself with three elements - a service 1445 element, representing the actual SMS service, a device element, 1446 modeling the phone, and a presentity element, modeling the user. 1447 Similarly, the PTT app has three elements, representing the PTT 1448 service, device, and presentity. 1450 If the user is in a PTT call, the PTT application might generate a 1451 document that looks like this. Note the inclusion of the busy 1452 element as part of the presentity state, which was set based on the 1453 silent switch: 1455 1456 1458 1459 urn:esn:600b40c7 1460 1461 1462 INVITE 1463 OPTIONS 1464 BYE 1465 ACK 1466 CANCEL 1467 1468 1471 1472 closed 1473 1474 sip:gruu-aa@example.com 1475 1476 1477 1478 1479 on-the-phone 1480 busy 1481 1482 1483 1484 1485 1486 mobile 1487 1488 1489 1491 The SMS application would publish a document that looks like this: 1493 1494 1496 1497 urn:esn:600b40c7 1498 1499 open 1500 1501 sms:1234567 1502 1503 1504 1505 1506 busy 1507 on-the-phone 1508 1509 1510 1511 1512 1514 The presence server now has two presence documents for a single user. 1515 It has conflicting information for the person and device elements. 1516 It knows it has two services, both of which run on the same device. 1517 It merges the two devices into one, and unions the information it has 1518 for them. It keeps the services as separate, but changes the PTT URI 1519 from the GRUU to the AOR. It merges the person information together, 1520 unioning that as well. The resulting raw presence document, after 1521 composition, would look like: 1523 1524 1526 1527 urn:esn:600b40c7 1528 1529 open 1530 1531 sms:1234567 1532 1533 1534 urn:esn:600b40c7 1535 1536 1537 INVITE 1538 OPTIONS 1539 BYE 1540 ACK 1541 CANCEL 1542 1543 1546 1547 closed 1548 1549 sip:someone@example.com 1550 1551 1552 1553 1554 busy 1555 1556 1557 1558 1559 1560 mobile 1561 1562 1563 1565 10. Security Considerations 1567 The presence information described by the model defined here is very 1568 sensitive. It is for this reason that privacy filtering plays a key 1569 role in the processing of presence data, as described above. 1570 Presence systems based on this model need to provide such a privacy 1571 capability, and furthermore, need to protect the integrity and 1572 confidentiality of the data. 1574 11. Acknowledgements 1576 This document is really a distillation of many ideas discussed over a 1577 long period of time. These ideas were contributed by many different 1578 participants in the SIMPLE working group. Henning Schulzrinne 1579 initially described the "pivot" operation described above for 1580 composition. Brian Rosen deserves credit for the "presentity view". 1581 Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert 1582 Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson 1583 contributed many of the concepts that are described here. A special 1584 thanks to Steve Donovan for discussions on the topics discussed here. 1586 12 Informative References 1588 [1] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 1589 Instant Messaging", RFC 2778, February 2000. 1591 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1592 Package for Registrations", RFC 3680, March 2004. 1594 [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 1595 J. Peterson, "Presence Information Data Format (PIDF)", RFC 1596 3863, August 2004. 1598 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1599 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1600 Session Initiation Protocol", RFC 3261, June 2002. 1602 [5] Rosenberg, J., "A Presence Event Package for the Session 1603 Initiation Protocol (SIP)", RFC 3856, August 2004. 1605 [6] Sparks, R., "SIMPLE Presence Document Usage Examples", 1606 draft-sparks-simple-pdoc-usage-00 (work in progress), October 1607 2003. 1609 [7] Roach, A., "Identification of Services in RPID (Rich Presence 1610 Information Data)", draft-roach-simple-service-features-00 1611 (work in progress), February 2004. 1613 [8] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, 1614 "RPID: Rich Presence: Extensions to the Presence Information 1615 Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in 1616 progress), March 2004. 1618 [9] Rosenberg, J., "Presence Authorization Rules", 1619 draft-ietf-simple-presence-rules-00 (work in progress), May 1620 2004. 1622 [10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 1623 August 2004. 1625 [11] Rosenberg, J., "Obtaining and Using Globally Routable User 1626 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1627 (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. 1629 [12] Niemi, A., "An Event State Publication Extension to the Session 1630 Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in 1631 progress), May 2004. 1633 [13] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User 1634 Agent Capabilities in the Session Initiation Protocol (SIP)", 1635 RFC 3840, August 2004. 1637 [14] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 1638 Preferences for the Session Initiation Protocol (SIP)", RFC 1639 3841, August 2004. 1641 [15] Lonnfors, M. and K. Kiss, "User agent capability presence 1642 status extension", draft-ietf-simple-prescaps-ext-01 (work in 1643 progress), May 2004. 1645 [16] Khartabil, H., "An Extensible Markup Language (XML) Based 1646 Format for Event Notification Filtering", 1647 draft-ietf-simple-filter-format-02 (work in progress), August 1648 2004. 1650 [17] Schulzrinne, H., "Timed Presence Extensions to the Presence 1651 Information Data Format(PIDF) to Indicate Presence Information 1652 for Past and Future Time Intervals", 1653 draft-ietf-simple-future-02 (work in progress), July 2004. 1655 [18] Schulzrinne, H., "CIPID: Contact Information in Presence 1656 Information Data Format", draft-ietf-simple-cipid-03 (work in 1657 progress), July 2004. 1659 [19] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short Message 1660 Service", draft-wilde-sms-uri-06 (work in progress), July 2004. 1662 [20] Mealling, M., "A UUID URN Namespace", 1663 draft-mealling-uuid-urn-03 (work in progress), March 2004. 1665 [21] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1666 Event Package for the Session Initiation Protocol (SIP)", 1667 draft-ietf-sipping-dialog-package-04 (work in progress), 1668 February 2004. 1670 [22] Schulzrinne, H., "The tel URI for Telephone Numbers", 1671 draft-ietf-iptel-rfc2806bis-09 (work in progress), June 2004. 1673 [23] Isomaki, M., "An Extensible Markup Language (XML) Configuration 1674 Access Protocol (XCAP) Usage for Manipulating Presence 1675 Document Contents", 1676 draft-ietf-simple-xcap-pidf-manipulation-usage-01 (work in 1677 progress), June 2004. 1679 Author's Address 1681 Jonathan Rosenberg 1682 dynamicsoft 1683 600 Lanidex Plaza 1684 Parsippany, NJ 07054 1685 US 1687 Phone: +1 973 952-5000 1688 EMail: jdrosen@dynamicsoft.com 1689 URI: http://www.jdrosen.net 1691 Intellectual Property Statement 1693 The IETF takes no position regarding the validity or scope of any 1694 Intellectual Property Rights or other rights that might be claimed to 1695 pertain to the implementation or use of the technology described in 1696 this document or the extent to which any license under such rights 1697 might or might not be available; nor does it represent that it has 1698 made any independent effort to identify any such rights. Information 1699 on the procedures with respect to rights in RFC documents can be 1700 found in BCP 78 and BCP 79. 1702 Copies of IPR disclosures made to the IETF Secretariat and any 1703 assurances of licenses to be made available, or the result of an 1704 attempt made to obtain a general license or permission for the use of 1705 such proprietary rights by implementers or users of this 1706 specification can be obtained from the IETF on-line IPR repository at 1707 http://www.ietf.org/ipr. 1709 The IETF invites any interested party to bring to its attention any 1710 copyrights, patents or patent applications, or other proprietary 1711 rights that may cover technology that may be required to implement 1712 this standard. Please address the information to the IETF at 1713 ietf-ipr@ietf.org. 1715 Disclaimer of Validity 1717 This document and the information contained herein are provided on an 1718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1725 Copyright Statement 1727 Copyright (C) The Internet Society (2004). This document is subject 1728 to the rights, licenses and restrictions contained in BCP 78, and 1729 except as set forth therein, the authors retain all their rights. 1731 Acknowledgment 1733 Funding for the RFC Editor function is currently provided by the 1734 Internet Society.