idnits 2.17.1 draft-thomson-simple-cont-presence-val-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (July 2, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-07 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-06 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-event-rate-control-00 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-03 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-location-quality-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE M. Thomson 3 Internet-Draft Andrew 4 Intended status: Informational July 2, 2009 5 Expires: January 3, 2010 7 Requirements for the Support of Continuously Varying Values in Presence 8 draft-thomson-simple-cont-presence-val-req-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 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 Internet- 18 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 January 3, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The attributes of continuous-valued data are examined in respect to 47 presence systems. The limitations of the existing presence system 48 with respect to continuous-valued data is examined. Requirements are 49 formulated that would enable the use of the presence system for this 50 data, with an emphasis on providing the watcher with a means of 51 control over the measurement process. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 4 57 2. Continous-Valued Data . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Continuous and Discrete Values in Presence . . . . . . . . 5 59 2.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Logical Model: Presence Sources . . . . . . . . . . . . . . . 7 61 3.1. The Presence Agent is a Cache . . . . . . . . . . . . . . 8 62 3.2. The Role of the Presentity . . . . . . . . . . . . . . . . 8 63 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Unguided Measurement . . . . . . . . . . . . . . . . . . . 10 65 4.2. Presence Filters . . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Quality . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. Watcher Feedback . . . . . . . . . . . . . . . . . . . . . 13 68 4.5. Active and Passive Sources . . . . . . . . . . . . . . . . 13 69 4.6. Triggering Measurement . . . . . . . . . . . . . . . . . . 14 70 4.6.1. Immediate Triggering of Measurement . . . . . . . . . 14 71 4.6.2. Periodic Triggering of Measurement . . . . . . . . . . 15 72 4.6.3. Value-based Triggering of Measurement . . . . . . . . 16 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. Quality Requirements . . . . . . . . . . . . . . . . . . . 18 75 5.2. Immediate Triggering Requirements . . . . . . . . . . . . 19 76 5.3. Periodic Triggering Requirements . . . . . . . . . . . . . 19 77 5.4. Value-Seeking Requirements . . . . . . . . . . . . . . . . 20 78 5.5. Timeliness Requirements . . . . . . . . . . . . . . . . . 20 79 5.6. Privacy Requirements . . . . . . . . . . . . . . . . . . . 21 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 85 Appendix A. Presence Agent and Source Interactions . . . . . . . 28 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 1. Introduction 90 The provision of continuously varying parameters using presence 91 requires specific support by the presence infrastructure [RFC2778]. 92 Existing methods assume that perfect information is always available 93 to the Presence Agent (PA). These methods rely on filtering, which 94 limit the data provided to a watcher, but do not provide the watcher 95 any control over the quality of the actual data. The current 96 presence system is ill-equipped to handle imperfect data. 98 Perfect information is available with no delay; perfect information 99 is absolutely accurate. The absence of perfectly accurate 100 information, can be inversely characterized as the existence of 101 uncertainty. The measurement of any physical property is subject to 102 some degree of uncertainty. The impact of this depends on the 103 purpose that the information is intended for. If a low standard of 104 quality is demanded of the data, the existence of uncertainty might 105 be ignored without negative consequences; near-perfect information is 106 often perfectly adequate. However, in some cases uncertainty can be 107 significant to the intended use of the information. 109 Timely availability of information also affects the service provided 110 by the PA. For a continuously varying value, the amount of time 111 required to acquire a value increases as the required accuracy 112 increases. The relationship between time and accuracy is likely to 113 be non-linear; gains in accuracy progressive require increasing 114 amounts of time to acquire. Futhermore, as a value changes over 115 time, the value provided to a watcher could be invalidated by the 116 time the watcher receives the information. 118 Dealing with imperfect information using presence requires additional 119 protocol support. To properly support continuous-valued data the 120 presence system needs to provide a way for a watcher to indicate 121 their preferences for data quality and timeliness. This document 122 outlines requirements for presence that enable the use of 123 continuously varying parameters. 125 Location information is used throughout this document as an exemplary 126 example of a continuous-valued datum. The requirements in this 127 document are intended to provide a basis for the definition of 128 presence features that support location while giving due 129 consideration to support of other continuous variables. 131 This document specifies requirements that might already be covered 132 by existing publications. To ensure the integrity of the overall 133 concept - and guarantee is completeness - those requirements are 134 retained. References are provided to relevant documents. 136 1.1. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Continous-Valued Data 144 Continuous-valued data are defined by this document as having a 145 continuous value space. Therefore, the set of possible values for 146 any Continuous-valued datum is infinite. In contrast, many existing 147 presence elements are discrete-valued. Discrete-valued elements have 148 a limited number of possible values. Continuous-valued data is most 149 regularly numerical, or is composed of numerical data. 151 Physical properties are the prototypical example of the use of 152 continuous-valued data. Any value expressed in the SI units (metres, 153 kilograms, seconds, ampere, kelvin, mole or candela) and units 154 derived from these are the focus of this document. 156 Examples of continuous-valued presence elements could include 157 descriptions of the physical characteristics of a presentity or its 158 immediate environment. This could include position in space; weather 159 related values such as ambient temperature and wind speed; light or 160 noise intensity; remaining battery life of a device; weight and size. 162 2.1. Continuous and Discrete Values in Presence 164 The many elements defined in RFC 4480 [RFC4480] are all discrete- 165 valued. Some of these discrete-valued presence elements are a 166 product of an underlying continuous value, others are created 167 subjectively. For instance, the "sphere" element could be derived 168 from the location of the presentity. 170 Discrete-valued data is easy to manipulate and use. However, the 171 process by which discrete-valued data is determined varies. When 172 discrete-valued data is derived from continuous variables, the 173 process might require heuristics that could be incompatible with the 174 needs of all watchers. Alternatively, where the process is 175 subjective, active user input is required. 177 Derivation of discrete-valued data from continuous primitives places 178 assumptions and restrictions on the resulting value. Access to 179 uninterpreted continuous values avoids any limitations that these 180 might impose and can enable a wider range of applications. 182 2.2. Measurement 184 The act of determining a continuous value is an act of measurement. 185 The value that is represented in a presence document is the product 186 of a measurement process. All measurement processes are subject to 187 measurement uncertainty, a well-documented phenomenom [ISO.GUM]. 189 This document applies to the inclusion of continuous-valued data in 190 presence, with any of the following constraints: 192 1. The process of measurement has non-zero - or at least non- 193 negligible - cost. Cost can be defined in any number of ways, 194 but could include time, processing resources, network 195 utilisation, labour or financial. 197 2. The measurement process has limited accuracy, resulting in 198 uncertainty that is - or could be - significant. 200 Cost and accuracy are often related. Improvements in one result in 201 degradation of the other. For continuous-valued information that is 202 not subject to these constraints, some requirements from this 203 document could still apply. 205 From the above constraints, one aim of any system that handles such 206 continuous-valued data is to minimise both cost and uncertainty using 207 different trade-offs. A common factor amoungst systems that handle 208 continuous-valued data is the desire to be able to ignore the effects 209 of these constraints. Where ignorance is not viable, systems exhibit 210 a range of traits: iterative measurement collection, caching of 211 results, fuzzy logic, maximum likelihood estimation and other forms 212 of statistical analysis. 214 A significant example of a continuously varying parameter is the 215 position of an entity in space, or its location. Location 216 information as an element of presence was established in [RFC4079] 217 and a format specified in [RFC4119]. Uncertainty in location 218 information, described in more detail in 219 [I-D.thomson-geopriv-uncertainty], is a product of the method of 220 location generation used and can vary greatly; likewise, the amount 221 of time required to ascertain location within specific quality 222 constraints is highly variable. 224 3. Logical Model: Presence Sources 226 The entity that measures continuous-valued data - and the process of 227 measurement - are crucial in determining the resulting information. 228 RFC 3856 [RFC3856] notes that presence data can be sourced by a 229 variety of means, but does not attach any significance to the source 230 of presence data. This document adopts a model that distinguishes 231 between the PA and the presence source. 233 +----------+ +----------+ +---------+ 234 | Presence |_____________| Presence |______________| Watcher | 235 | Source | (Various) | Agent | (Presence) | | 236 +----------+ +----------+ +---------+ 238 Figure 1: Logical Model 240 Specifics of the interaction between presence source and PA are out 241 of scope for this document. There might be formalised protocols, or 242 the PA might use unspecified or informal methods to acquire data. 243 Formalised exchanges include SIP PUBLISH [RFC3903]; informal 244 interactions include those that are briefly described in Section 7 of 245 [RFC3856]. 247 For location information, the GEOPRIV architecture [RFC3693] defines 248 the Location Generator. The Location Generator is the presence 249 source of this model; the entity that generates, or measures, the 250 continuous value. In the GEOPRIV architecture the Location Server is 251 the analogue of the PA and the Location Recipient corresponds to the 252 watcher. Other forms of continuous-valued data might have similarly 253 formal architectures and nomenclature. 255 In an end-to-end system, the model can be applied iteratively. An 256 entity that acts as a presence source to a PA could equally acquire 257 its information from a separate source; from a different perspective, 258 the PA becomes a watcher and the presence source becomes a PA. 260 +----------+ +----------+ +---------+ 261 | Presence | | Presence |____| Watcher | 262 | Source | | Agent | | | 263 +----------+ | - or - +----+ - or - | +---------+ 264 | Presence |____| Presence | | Watcher | 265 | Source | | Agent | | | 266 +----------+ +----------+ +----------+ 268 Figure 2: Iterative Application of the Logical Model 270 3.1. The Presence Agent is a Cache 272 Caching is a tool that is widely used in protecting resources where 273 multiple watchers require access to the same information. After a 274 presence datum is acquired from a source, requests within a set 275 period are served from a cache to reduce the time required to serve 276 the request and to avoid the costs in gathering the data. 278 For discrete-valued data, it is often feasible to provide data that 279 is correct at the time that a watcher receives a notification. The 280 caching behavior of the PA is effectively hidden. 282 Continuous-valued data differs in that the information provided can 283 never be absolutely correct. As the number of watchers increases, 284 the extent to which a PA relies on caching necessarily increases. 285 The PA provides a value from some time in the past, with a certain 286 accuracy. 288 In presence, caching is also used by the watcher user agent, which 289 maintains a cached presence document for each presentity. This 290 cache is updated when the PA notifies the watcher of changes. 292 How useful cached information is depends on how the information is 293 applied. This caching behavior can become apparent to watchers when 294 the information that they receive is inadequate for their needs. 296 Many caching management mechanisms, such as that defined in HTTP 297 [I-D.ietf-httpbis-p6-cache], rely solely on age. As a metric with a 298 single axis, time can be precisely controlled. There is no need to 299 trade off multiple conflicting constraints, the data is either 300 current enough, or not. Acquisition of continuous-valued data often 301 involves quality and timeliness constraints in addition to age 302 constraints. 304 3.2. The Role of the Presentity 306 As the subject of presence information, there are two main aspects to 307 the presentities involvement in this model. The presentity can, in 308 some circumstances, act as a presence source, even though the model 309 does not require any direct involvement. More significantly, in all 310 cases the presentity has the most significant stake in ensuring that 311 it retains some measure of control over the process. 313 The presentity exercises control over the dissemination of presence 314 information through use of policy. Enforcement of policy is 315 performed by the PA. Policy is used to restrict what presence 316 information is made available to watchers. This document describes 317 requirements for policy that also limit what controls the watcher is 318 given over the measurement of continuous-valued presence information. 320 Note: The GEOPRIV model assigns the label of "Rule Maker" to the 321 role assumed by the presentity when setting policy. The Rule 322 Maker role is further extended to include other stakeholders. The 323 requirements in this document do not preclude this abstraction. 325 In some cases, a presentity also acts as a presence source. A 326 presentity could exploit this confluence by restricting the 327 information that it provides as a presence source, thereby obviating 328 the need for certain aspects of policy. This can be an advantageous 329 circumstance, particularly where the PA limits the complexity and 330 size of the policy it accepts. 332 4. Problem Statement 334 Continuous-valued data cannot always be treated in the same fashion 335 as discrete-valued data. This section outlines a number of 336 considerations that distinguish continuous-valued data. These 337 considerations affect how the presence system uses continuous-valued 338 data. 340 4.1. Unguided Measurement 342 A presence source is responsible for the measurement of presence 343 data. Unless the watcher is able to communicate preferences to the 344 presence source, the process of measurement is unguided. 346 In the event that a PA and watcher operate independently of the 347 presence data source, there is a risk that continuous-valued data is 348 measured inappropriately. Values might be measured too frequently or 349 with unneeded degree of accuracy; that is, accuracy is favored too 350 highly over cost. Conversely, if cost is optimised, measurements 351 might be insufficient in frequency or accuracy. 353 Communicating watcher preferences to the presence source addresses 354 this problem by making watcher preferences known to the presence 355 source. With this information the measurement process is no longer 356 unguided. 358 Communicating watcher preferences to the presence source is 359 especially critical if the watcher also incurs costs relating to the 360 measuring of the continuous value. The most direct cost is in time: 361 the watcher might be forced to wait for measuring of information to 362 an accuracy more stringent than needed. However, it need not be 363 limited to time. 365 4.2. Presence Filters 367 It is possible to resolve the problem of unguided measurement without 368 resorting to explicit protocol mechanisms. Presence filters 369 ([RFC4660], [RFC4661]) are a vessel for conveying a watcher's 370 preferences to the PA. If the PA has a means of communicating with a 371 presence source, it is able to request measurement of continuous- 372 valued data according to the preferences it is aware of. By 373 communicating the watcher's preferences in this manner, the presence 374 source is able to measure accordingly. Additional changes to 375 presence subscriptions ([I-D.ietf-sipcore-event-rate-control]) and 376 filter extensions ([I-D.ietf-geopriv-loc-filters]) make more 377 information available to the PA; this information could be passed on. 379 Figure 3 shows a simplified model of the existing system of filtering 380 for presence data. The system assumes that presence information is 381 perfect. If this is not the case, the only option for a PA is to 382 project the illusion that this is the case. The only information 383 available to the PA is the filter and throttling data made available 384 to it in the subscription. This information is then used to advise 385 presence sources and to shape the notifications the PA provides. 387 +--------------------------------------------------------+ 388 | Presence Agent (PA) | 389 | | 390 | ,----------------+<-------+<-------+<------------- 391 | / (Presentity / / / SUBSCRIBE | 392 | | Identifier) / / / | 393 | V | | | | 394 | ,----------. | | | | 395 | | | V | V | 396 | | Presence | \---------\ : \----------\ | 397 | | Data |---->) Filter )------>) Throttle )----------> 398 | | Cache | /---------/ : /----------/ NOTIFY | 399 | | | | | / | 400 | `----------' | / / | 401 | ^ ^ ^ |,-----+-------' | 402 | | | | / | 403 | .-+--+--+-. / | 404 | / Trigger \ <-----' +----------+ | 405 | ^--+--+--+--^ | Internal | | 406 | | \ `-----------------------| Presence | | 407 | | `. | Source | | 408 | | `-. +----------+ | 409 | | `. | 410 +----+-----------+---------------------------------------+ 411 | \ 412 | `. 413 +----------+ +----------+ 414 | Presence | | Presence | 415 | Source | | Source | 416 +----------+ +----------+ 418 Figure 3: Presence Agent Model 420 4.3. Quality 422 Ensuring that a watcher is able to access information that meets 423 their needs is an important goal of presence filters. When it comes 424 to information quality, there are two separate goals that need to be 425 distinguished: 427 o A filter is used to determine when (and if) the PA notifies the 428 watcher of changed presence information. This filter is usually 429 strictly boolean, or "hard": unless the condition is met, no 430 notification is generated. 432 o A target quality is used to inform the presence source (the 433 measurement process) of the desired quality of the result. This 434 target is "soft": if the stated quality cannot be provided, a 435 notification might still be generated. In this way, this 436 information acts as a goal for the presence source, rather than a 437 condition on the notification process. 439 The difference between the soft target and hard filter could 440 alternatively be characterised as "want" and "need". The concept of 441 a soft target is not necessary for discrete-valued presence data. 443 Suppose a watcher, Bob, is watching the location of a presentity, 444 Alice. Bob specifies a hard filter that specifies a maximum 445 uncertainty of 50m. If this is used to advise the presence 446 source, the source attempts to determine a location within that 447 uncertainty. If the source is unable to meet the requirement, the 448 filter ensures that no notification is sent to Bob. 450 However, Bob could handle uncertainty of up to 1000m; it's not 451 ideal, but some information is better than none. If he specified 452 a larger constraint using the hard filter, the source might use 453 cheaper methods that never produce a result with the accuracy Bob 454 really wants. Therefore, Bob provides two values: a soft target 455 of 50m, and a hard cutoff at 1000m uncertainty. 457 From this example, it can be seen that soft quality preferences are 458 useful where continuous-valued data is the subject. In comparison, 459 the hard filter is not tolerant of variations in quality. The soft 460 preferences are used to guide the measurement process, but aren't 461 restrictive and don't unnecessary filter out poor quality results. 463 Location-specific standards such as the Mobile Location Protocol 464 (MLP) [OMA.MLS] provide a means to specify either hard or soft 465 quality constraints. A service class of "assured" implies that 466 constraints are hard, whereas "best effort" service class 467 indicates the use of a soft constraint. 469 Quality constraints can be used to bypass caching of data. For 470 instance, a constraint might be placed on the timestamp that forces 471 the measurement of new data. This is discussed in more detail in 472 Section 4.6.1. 474 4.4. Watcher Feedback 476 A watcher requires adequate feedback from the PA about how its 477 preferences are being acted upon. To a watcher, a PA that fully 478 communicates watcher preferences to a presence source, remains 479 indistinguishable from a PA that is either less able to acquire data 480 (because it relies on PUBLISH [RFC3903]), or simply chooses not to 481 perform this communication. 483 In some cases, a watcher is able to compensate for any limitations 484 imposed by the PA. As shown in Section 4.6.3 adaptive polling can be 485 used to seek a particular value. However, if a watcher uses polling 486 for value-seeking, this potentially duplicates similar efforts from 487 the PA or presence source. 489 In other circumstances, shortcomings cannot be addressed by the 490 watcher. For instance, perhaps the presence source is capable of 491 providing information to a certain high degree of accuracy, but 492 unless requested it does not do so (the cost is too high). If the PA 493 never requests highly accurate information, that information is never 494 available to the watcher. 496 Providing the watcher feedback on what efforts the PA and presence 497 source make to acquire information ensures that the watcher is able 498 to avoid replicating behaviour. It also ensures that the watcher is 499 able to make requests with some assurance that the PA is attempting 500 to address them. 502 4.5. Active and Passive Sources 504 For a particular presence datum, the means by which the PA is able to 505 acquire updated information varies. For some forms of discrete- 506 valued data - such as basic status - the PA might be considered 507 absolutely authoritative, in that the information is absolutely 508 correct by definition. Data can be made available to the PA either 509 passively or actively: 511 Passive Acquisition: The PA is a passive recipient of updated 512 information with no means to trigger measurement. SIP PUBLISH 513 [RFC3903] is an example of how the PA could passively acquire 514 data. 516 Active Acquisition: The PA is able to seek updated information, and 517 does so based on one or more triggers. 519 Providing the watcher information on the nature of a particular 520 presence source is an important part of the feedback provided by the 521 PA. If the PA only passively acquires data, much of the 522 considerations presented in this document become moot. More 523 significantly, if the watcher is not able to influence how the PA 524 interacts with the presence source, the watcher is not able to 525 specify constraints on the data it receives. Thus, only when the PA 526 conveys watcher preferences, does active acquisition becomes truly 527 effective in improving the usefulness of presence data. 529 Back to Bob and Alice: This time, Bob wants to know when Alice 530 passes by the library where Bob works. Bob sets a filter, 531 requesting that he only be notified when Alice passes within 100m 532 of the library. If the PA passively receives updates about 533 Alice's location from a presence source and does not inform the 534 source of Bob's desired result, it could be that it never receives 535 information when Alice passes by. The presence source might not 536 publish the necessary information at the moment that Alice passes 537 by and Bob is not informed even though the event he was interested 538 in actually occurs. 540 4.6. Triggering Measurement 542 Stimulating the generation of a value for the continuous variable can 543 be done through several methods: 545 o immediate or on-demand triggers 547 o time-based or periodic triggers (polling) 549 o value-based triggers 551 4.6.1. Immediate Triggering of Measurement 553 An immediate request for measurement provides the simplest means of 554 directly providing the presence source with necessary information. A 555 watcher makes a request to the PA, including its preferences. The PA 556 then acquires information from the presence source, passing watcher 557 preferences directly to the source. 559 An immediate request for updated information is particularly useful 560 for suppressing caching behavior at the PA or other entities. 562 PA caching can interfere with certain use cases, particularly those 563 where currency of information is valued over efficiency. For 564 instance, if a watcher wants to know what the ocean temperature off 565 the coast of Madagascar is _now_; if cached data is too old to 566 useful, a caching mechanism could interfere with that goal. Measures 567 to suppress and control caching are necessary. 569 The simplest mechanism for avoiding cached data is to specify a 570 quality constraint that limits the age of information. Setting this 571 age value to zero indicates to any caching entity that old 572 information is no good. As long as the caching policy allows it, the 573 cache is avoided. Values larger than zero indicate how old the 574 cached information can be to be used. This ensures that the benefits 575 of caching are achieved without negative affecting the watcher. 577 The HTTP "Cache-Control" header [I-D.ietf-httpbis-p6-cache] 578 provides this function. A reqeuester is given explicit control 579 over whether a cache is used. "Cache-Control" directives relate 580 to the age of the information; a header set with "no-cache" 581 prevents the use of data from cache. 583 4.6.1.1. Immediate SIP SUBSCRIBE 585 For SIP presence, the means of triggering immediate measurement is 586 the SUBSCRIBE request. This presents a challenge for the SIP 587 presence framework if the presence source is not able to provide the 588 requested information immediately. RFC 3265 [RFC3265] states: 590 When a SUBSCRIBE request is answered with a 200-class response, 591 the notifier MUST immediately construct and send a NOTIFY request 592 to the subscriber. 594 If the PA is unable to provide an immediate notification due to lack 595 of information, it must indicate this to the watcher. A presence 596 document might be a composit of continuous- and discrete-valued data. 597 Any solution for continuous-valued data cannot affect the conveyance 598 of discrete-valued data. Compatibility with existing the existing 599 presence framework is also desirable. Therefore, an immediate 600 notification is still necessary. 602 Some time after the initial request, when the continuous-valued data 603 becomes available, a second notification can be sent. However, 604 another conflict arises with event rate throttling 605 [I-D.ietf-sipcore-event-rate-control]. When information becomes 606 available, the notification might be suppressed due to a short 607 elapsed time since the initial notification. 609 Any means of triggering immediate measurement needs to consider these 610 problems. 612 4.6.2. Periodic Triggering of Measurement 614 Periodic notifications of the value of presence data are not assumed 615 to be necessary by the existing work. Values are assumed to change 616 infrequently, or if frequent changes are necessary, solutions have 617 concentrated on means of throttling notifications. RFC 3265 619 [RFC3265] recommends that event packages specify a minimum interval 620 between notifications; and [I-D.ietf-sipcore-event-rate-control] 621 provides a direct means of controlling this interval. 623 If the watcher has an interest in the value of a particular datum 624 over time, it is useful to be able to have the PA provide 625 notifications at regular intervals. 627 A similar time-based problem exists for periodic notification as did 628 for the immediate request. The PA cannot request presence 629 information at the time that a notification is required - the 630 presence source is unlikely to be able to produce a result so 631 quickly. The PA needs to allow the presence source sufficient time 632 to make a measurement. This time can be allocated before the 633 notification is required so that all the necessary data is available 634 for the notification. 636 Deciding how much time to allow the presence source for measurement 637 presents another problem. Relying upon a value specified by the 638 watcher ensures that the measurement process is guided appropriately. 640 4.6.3. Value-based Triggering of Measurement 642 A watcher might only be interested in a value if that value enters a 643 particular range. For instance, for location, the watcher might be 644 interested when the presentity is in the vicinity of a particular 645 landmark, or even the when two presentities approach each other. A 646 watcher that monitors the temperature of a presentity might be 647 interested if the temperature exceeds a certain threshold. 649 Value-seeking can be performed in different ways. Given certain 650 assumptions or knowledge about the rate of change of a value and the 651 desired responsiveness, an adaptive polling method can be used. The 652 rate of polling can increase in frequency in proportion to the 653 proximity of the current value to the target range. In addition, 654 time and quality constraints can be relaxed or made more stringent as 655 appropriate. The advantage of polling is that it can be performed 656 based on the value only. The additional knowledge available to a 657 presence source is not necessary; a PA or watcher is able to use 658 polling for value-seeking. 660 A presence source can potentially use alternative information to 661 assist in value-seeking. For data that is derived from other 662 measurements, the value of the unprocessed measurements might provide 663 an adequate indication of the value to obviate any need to continue 664 measurement. For instance, the set of wireless transmitters that can 665 be observed by a wireless device can be used as a rough indication of 666 location. 668 Value-seeking can be of great benefit to applications, particularly 669 for simplifying the application logic. Without this feature, an 670 application needs accept and interpret notifications and check values 671 against a target range. As demonstrated in 672 [I-D.thomson-geopriv-uncertainty], this can be non-trivial. If a 673 trigger can be set based on a certain value, the notification 674 provided by the PA indicates that the condition has been met. 676 Lee is a surfer. He uses a presence service to inform him of when 677 the waves are good at his favourite beaches. During the week, 678 when Lee is usually at work, Lee sets a trigger that notifies him 679 when the waves reach a certain size at any one of these beaches. 680 If the waves reach the size that means that surfing becomes a 681 higher priority than working, Lee is sent a text message. Upon 682 receiving the text message, he drops what he is doing to catch the 683 big surf. 685 This case can also be used to demonstrate one reason for using 686 continuous-valued data instead of discrete-valued data. Harriette 687 might also be an equally keen surfer, but less flexible 688 employment. She has to set a more stringent set of criteria 689 before she is willing to renege on her responsibilities. Giving 690 both surfers access to the raw data lets them set their own 691 definition for what is worth skipping out on work. Any discrete 692 value that is assigned reflects a certain set of values that 693 cannot be universally accurate. 695 5. Requirements 697 The requirements documented in this section relate to subscriptions 698 for continuous-valued data. These requirements do not make any 699 assumptions about the nature of the relationship between PA and 700 presence source. A presence source is assumed to be present only to 701 the extent that the measurement of a particular presence element 702 affects the results observed by the watcher. 704 A solution that addresses these requirements MAY address them based 705 on a specific type of data. A generic solution might not be feasible 706 in all cases. 708 5.1. Quality Requirements 710 Q1. The system MUST provide a watcher the ability to express non- 711 binding requirements on information quality for continuous- 712 valued presence data. 714 Motivation: Having a means to express preferences in non-binding 715 fashion can have the desired effect in influencing the 716 measurement process at the presence source without other side- 717 effects. 719 Q2. The system MUST provide a means to indicate how information 720 quality preferences are used or propagated. 722 Motivation: Providing adequate feedback to a watcher assists the 723 watcher in making decisions about its behaviour. From the 724 perspective of a PA, this requirement can only be fulfilled 725 based on the knowledge it has available. A PA can know whether 726 or not it is the presence source, but it cannot assume that the 727 entity it requests information from is the ultimate source of 728 the information; a PA needs to - in turn - rely on the 729 information provided by its source. This ensures that a watcher 730 is able to learn how its preferences are getting to the ultimate 731 source. 733 For instance, the PA or presence source might limit the extent 734 to which quality parameters are able to bypass caches. This 735 information can be integrated with any inherent limitations 736 indicated by the source, or the mechanism used to acquire the 737 presence data. 739 5.2. Immediate Triggering Requirements 741 IT1. The system MUST provide a means for a watcher to explicitly and 742 immediately request measurement of a specified continuous- 743 valued datum, bypassing any cached data. 745 Motivation: A direct request for data ensures that the presence 746 source is properly advised of the constraints of a request. It 747 also ensures that a watcher has access to updated information. 749 IT2. The system MUST provide a means for the watcher to communicate 750 time constraints on measurement processes. 752 Motivation: Specifying time constraints ensures that the 753 information is available to the watcher when required. It also 754 ensures that the presence source applies appropriate methods in 755 measuring. 757 IT3. The system MUST provide a means for a PA to limit support for 758 immediate requests. 760 Motivation: Making a direct request to the presence source 761 increases the load on the presence source and PA. A PA 762 implementation might want to constrain access to immediate 763 requests to prevent denial of service. 765 IT4. The system MUST provide a means for a PA to indicate support 766 for immediate requests, including any limits or constraints on 767 that support. 769 Motivation: Providing adequate feedback to the watcher ensures 770 that the watcher is able to modify its behaviour accordingly. 772 5.3. Periodic Triggering Requirements 774 References: [I-D.ietf-sipcore-event-rate-control] 776 PT1. The system MUST provide a means to request periodic measurement 777 of a continuous-valued datum at a specified interval. 779 Motivation: Periodic measurement is the most basic means of 780 enabling tracking of a value over time. More sophisticated 781 methods might be used, but this sets a minimum level of 782 capability that can be exploited for any type of continuous- 783 valued data. 785 PT2. The system MUST provide a means for a PA to limit support for 786 periodic requests. 788 Motivation: Excessive polling rates might result in denial of 789 service through excessive requests. 791 PT3. The system MUST provide a means for a PA to indicate support 792 for periodic measurement, including any limits or constraints. 794 PT4. The system MUST provide a means for a watcher to explicitly 795 limit the rate of notifications. 797 Motivation: Even without perfect information, the defining 798 characteristic of continuous variables is the potential for 799 continuous change. This manifests in presence as a continuous 800 stream of data from the PA to the watcher. For a range of 801 reasons - protection of network utilization not-withstanding - 802 this is not desirable. 804 5.4. Value-Seeking Requirements 806 VT1. The system MAY provide a means for a watcher to indicate a 807 particular range of values to seek. 809 Motivation: If a watcher is only interested in a certain range 810 of values, limiting measurement and notification protects 811 resources on both the presence source and watcher. 813 VT2. The system MUST provide a means for a PA to indicate support 814 for value-seeking requests, including any limits or constraints 815 on that support. 817 Motivation: Providing adequate feedback to the watcher ensures 818 that the watcher is able to modify its behaviour accordingly. 820 5.5. Timeliness Requirements 822 T1. Continuous-valued data MUST always have a timestamp that 823 indicates when the value was measured. 825 Motivation: A continuously varying datum is, by its nature, 826 inevitably out of date at the time that the watcher receives it. 827 In practice, this is only a problem if the time between 828 measurement and receipt of the data is large. Since this is a 829 matter of degree, providing a timestamp ensures that a watcher 830 is able to make a judgment about validity. 832 If time information is not included, the recipient of 833 continuous-valued information has no means of judging how 834 current the information is. PIDF [RFC3863] specifies an 835 optional "timestamp" element, which is described as being 836 necessary if available. This requirement makes the value 837 mandatory. 839 The corollary to this that an item of continuous-valued data is 840 automatically invalid if it is not timestamped. 842 T2. The system MUST provide a watcher the ability to limit the age 843 of data that it is provided. 845 Motivation: This ensures that caching of data is only used to 846 the extent that it is acceptable to the watcher. 848 References: [I-D.thomson-geopriv-location-quality], Requirement 849 IT1. 851 T3. The system SHOULD provide a means for a watcher to indicate how 852 long measurement of continuous-valued data is allowed to take. 854 Motivation: This indication assists the PA and presence source 855 in making decisions about how much time to allocate to 856 measurement; for periodic measurement, it provides a hint on 857 when to start measurement. This guidance is often better served 858 by other quality constraints in situations where the delay is 859 not evident to the watcher. However, a time-based value serves 860 in a wide range of scenarios and guides behaviour where a PA 861 might not understand the quality constraints specific to a data 862 type. 864 5.6. Privacy Requirements 866 P1. The system MUST provide a means for a presentity (rule maker) to 867 control how watchers are able to request continuous-valued data. 869 Motivation: A presence agent acts for the presentity in 870 disseminating presence information. Policy is the primary means 871 of privacy control available a presentity. 873 Many of the requirements in this document describe more flexible 874 means of acquiring presence information. Policy provides a 875 means for a presentity to limit a watcher's access to these 876 features and thereby restrict access to private data. 878 References: [RFC4745] 880 Each of the individual aspects of watcher-agent-source interaction 881 are appropriate subjects for policy: 883 Quality: A presentity might want to limit the quality of the 884 information provided. Quality can be purposefully degraded post- 885 measurement. If this restriction is known before measurement, the 886 presence source might be able to avoid some costs in generation. 888 Immediate Triggers: A presentity might want to restrict access to 889 immediate requests, or force the use of cached data. 891 Periodic Triggers: A presentity might want to prevent periodic 892 requesting, or place a limit on the rate that can be requested by 893 watchers. 895 Each of the mechanisms that allow for greater control at the watcher 896 MUST also consider policy controls to limit or block use of that 897 mechanism. This guarantees that a presentity (or rule maker) is able 898 to communicate appropriate rules to the PA. 900 6. Security Considerations 902 A number of requirements involve a PA making information about its 903 operation available to a watcher. This information might be consider 904 sensitive by the operators of a PA. Any solution that addresses 905 these requirements MUST provide an option to suppress this 906 information and MAY include guidance on when this might be 907 appropriate. 909 Many of the requirements in this document potentially result in PA 910 and presence source behaviour being controlled to some extent by a 911 watcher. A malicious watcher could attempt a denial of service 912 attack by exploiting the fact that some of this behaviour requires 913 greater expenditure resources from the PA and presence source than is 914 incurred in making the request. In particular, periodic requests or 915 requests that includes value-seeking require significant processing 916 in response to a relatively simple request. Any solution that 917 addresses these requirements MUST consider the implications of denial 918 of service on the PA and SHOULD also consider the presence source. 920 Caching of results can limit the load imposed by multiple requests 921 for the same information. To protect against denial of service, a PA 922 MAY choose to suppress any options for bypassing cached data. 924 Privacy is a major consideration in any architecture that defines 925 more flexible means of access to private data. Section 5.6 describes 926 requirements that are aimed at providing a presentity (or other rule 927 maker) greater control over the access watchers have to private data. 928 These focus on the application of policies that direct the actions of 929 the PA. 931 7. Acknowledgements 933 This document is a clumsy attempt to formalize the output of 934 discussions on the nature of presence and its applicability to 935 location information. Adam Roach has been helpful in destroying 936 misconceptions about presence. Jonathan Rosenberg pointed out a 937 major omission in ignoring the role of the presentity an earlier 938 version of this document. Thanks also to Richard Barnes, Jon 939 Peterson, Robert Sparks, James Winterbottom. 941 8. References 943 8.1. Normative References 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, March 1997. 948 8.2. Informative References 950 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 951 Presence and Instant Messaging", RFC 2778, February 2000. 953 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 954 Event Notification", RFC 3265, June 2002. 956 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 957 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 959 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 960 Initiation Protocol (SIP)", RFC 3856, August 2004. 962 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 963 W., and J. Peterson, "Presence Information Data Format 964 (PIDF)", RFC 3863, August 2004. 966 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 967 for Event State Publication", RFC 3903, October 2004. 969 [RFC4079] Peterson, J., "A Presence Architecture for the 970 Distribution of GEOPRIV Location Objects", RFC 4079, 971 July 2005. 973 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 974 Format", RFC 4119, December 2005. 976 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 977 Rosenberg, "RPID: Rich Presence Extensions to the Presence 978 Information Data Format (PIDF)", RFC 4480, July 2006. 980 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 981 Requena, "Functional Description of Event Notification 982 Filtering", RFC 4660, September 2006. 984 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 985 Requena, "An Extensible Markup Language (XML)-Based Format 986 for Event Notification Filtering", RFC 4661, 987 September 2006. 989 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 990 Polk, J., and J. Rosenberg, "Common Policy: A Document 991 Format for Expressing Privacy Preferences", RFC 4745, 992 February 2007. 994 [I-D.ietf-geopriv-lbyr-requirements] 995 Marshall, R., "Requirements for a Location-by-Reference 996 Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work 997 in progress), February 2009. 999 [I-D.ietf-geopriv-loc-filters] 1000 Mahy, R. and B. Rosen, "A Document Format for Filtering 1001 and Reporting Location Notications in the Presence 1002 Information Document Format Location Object (PIDF-LO)", 1003 draft-ietf-geopriv-loc-filters-03 (work in progress), 1004 November 2008. 1006 [I-D.ietf-httpbis-p6-cache] 1007 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1008 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 1009 "HTTP/1.1, part 6: Caching", 1010 draft-ietf-httpbis-p6-cache-06 (work in progress), 1011 March 2009. 1013 [I-D.garcia-simple-indirect-presence-publish] 1014 Garcia, M., Tschofenig, H., and H. Schulzrinne, "Indirect 1015 Presence Publication with the Session Initiation 1016 Protocol(SIP)", 1017 draft-garcia-simple-indirect-presence-publish-01 (work in 1018 progress), March 2009. 1020 [I-D.ietf-sipcore-event-rate-control] 1021 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 1022 Protocol (SIP) Event Notification Extension for 1023 Notification Rate Control", 1024 draft-ietf-sipcore-event-rate-control-00 (work in 1025 progress), May 2009. 1027 [I-D.thomson-geopriv-uncertainty] 1028 Thomson, M. and J. Winterbottom, "Representation of 1029 Uncertainty and Confidence in PIDF-LO", 1030 draft-thomson-geopriv-uncertainty-03 (work in progress), 1031 June 2009. 1033 [I-D.thomson-geopriv-location-quality] 1034 Thomson, M. and J. Winterbottom, "Specifying Location 1035 Quality Requirements in Location Protocols", 1036 draft-thomson-geopriv-location-quality-04 (work in 1037 progress), June 2009. 1039 [ISO.GUM] ISO/IEC, "Guide to the expression of uncertainty in 1040 measurement (GUM)", Guide 98:1995, 1995. 1042 [OMA.MLS] Open Mobile Alliance, "Mobile Location Service v1.2", 1043 Enabler MLS V1.2, 2008. 1045 Appendix A. Presence Agent and Source Interactions 1047 [[Ed: this section has some informational value, but need to 1048 determine how much that contributes to the document.]] 1050 This document specifies requirements that expose the nature of the 1051 association between PA and presence source. While there are no 1052 direct requirements on this interface and proprietary solutions are 1053 entirely appropriate, it is hoped that these requirements will 1054 influence the design of any protocol mechanisms used on this 1055 interface. 1057 Associations between PA and presence sources could be largely static 1058 in nature, as is true of the methods described in [RFC3856]. 1059 Establishing dynamic associations between PA and presence source is 1060 an option where disparate presence sources are required. This is 1061 especially true for location information, where close physical 1062 proximity between presentity and source is usually required; 1063 consequently the presence source can dynamically change as the 1064 presentity moves. 1066 Location by-reference [I-D.ietf-geopriv-lbyr-requirements] provides a 1067 means whereby a relationship between any entity and the Location 1068 Generator can be established. By contacting the Location Generator, 1069 a requester is able to specify preferences for how location 1070 information is generated/measured. A location reference forms the 1071 basis for establishing an association between Location Generator and 1072 a Location Server. 1074 For presence, Indirect publish 1075 [I-D.garcia-simple-indirect-presence-publish] describes how a PA is 1076 able to use the indirection provided by a URI. The URI is used to 1077 establish a link between the presence source and the PA. The URI is 1078 distinguished by two characteristics: 1080 o the host serving the URI is the presence source 1082 o additional information in the URI provides enough information to 1083 uniquely identify the presentity to the presence source 1085 Author's Address 1087 Martin Thomson 1088 Andrew 1089 PO Box U40 1090 Wollongong University Campus, NSW 2500 1091 AU 1093 Phone: +61 2 4221 2915 1094 Email: martin.thomson@andrew.com 1095 URI: http://www.andrew.com/