One document matched: draft-thomson-simple-cont-presence-val-req-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2778 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2778.xml">
<!ENTITY RFC3265 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC3856 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY RFC3863 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3863.xml">
<!ENTITY RFC3903 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY RFC4079 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4079.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC4480 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4480.xml">
<!ENTITY RFC4660 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4660.xml">
<!ENTITY RFC4661 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4661.xml">
<!ENTITY RFC4745 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml">
<!ENTITY I-D.ietf-geopriv-loc-filters PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-loc-filters.xml">
<!ENTITY I-D.ietf-geopriv-lbyr-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml">
<!ENTITY I-D.garcia-simple-indirect-presence-publish PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.garcia-simple-indirect-presence-publish.xml">
<!ENTITY I-D.niemi-sipping-event-throttle PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.niemi-sipping-event-throttle.xml">
<!ENTITY I-D.thomson-geopriv-uncertainty PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml">
<!ENTITY I-D.thomson-geopriv-location-quality PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-location-quality.xml">
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="info" ipr="full3978">
<front>
<title abbrev="Continuous Presence Reqs.">
Requirements for the Support of Continuously Varying Values in Presence
</title>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date month="December" year="2008"/>
<area>RAI</area>
<workgroup>SIMPLE</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Presence</keyword>
<keyword>Location</keyword>
<keyword>Continuous</keyword>
<keyword>GEOPRIV</keyword>
<abstract>
<t>The attributes of continuous-valued data are examined in respect to presence systems. The limitations of the existing presence system with respect to continuous-valued data is examined. Requirements are formulated that would enable the use of the presence system for this data, with an emphasis on providing the watcher with a means of control over the measurement process.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The provision of continuously varying parameters using presence requires specific support by the <xref target="RFC2778">presence infrastructure</xref>. Existing methods assume that perfect information is always available to the Presence Agent (PA). These methods rely on filtering, which limit the data provided to a watcher, but do not provide the watcher any control over the quality of the actual data. The current presence system is ill-equipped to handle imperfect data.
</t>
<t>Perfect information is available with no delay; perfect information is absolutely accurate. The absence of perfectly accurate information, can be inversely characterized as the existence of uncertainty. The measurement of any physical property is subject to some degree of uncertainty. The impact of this depends on the purpose that the information is intended for. If a low standard of quality is demanded of the data, the existence of uncertainty might be ignored without negative consequences. However, in some cases uncertainty can be significant to the intended use of the information.
</t>
<t>Timely availability of information also affects the service provided by the PA. For a continuously varying value, the amount of time required to acquire a value increases as the required accuracy increases. The relationship between time and accuracy is likely to be non-linear; gains in accuracy follow the law of diminishing returns. Futhermore, as an actual value changes over time, the value provided to a watcher could be invalidated by the time the watcher receives the information.
</t>
<t>Dealing with imperfect information using presence requires additional protocol support. To properly support continuous-valued data the presence system needs to provide a way for a watcher to indicate their preferences for data quality and timeliness. This document outlines requirements for presence that enable the use of continuously varying parameters.
</t>
<t>Location information is used throughout this document as an exemplary example of a continuous-valued datum. The requirements in this document are intended to provide a basis for the definition of presence features that support location while giving due consideration to support of other continuous variables.
</t>
<t><list style="empty"><t>This document specifies requirements that might already be covered by existing publications. To ensure the integrity of the overall concept—and guarantee is completeness—those requirements are retained. References are provided to relevant documents.
</t></list></t>
<section anchor="conventions" title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t><list style="empty"><t>Paragraphs that are indented like this one contain motivation, examples, speculation and other non-normative statements.
</t></list></t>
</section>
</section>
<section anchor="cont" title="Continous-Valued Data">
<t>Continuous-valued data are defined by this document as having a continuous value space. Therefore, the set of possible values for any Continuous-valued datum is infinite. In contrast, many existing presence elements are discrete-valued. Discrete-valued elements have a limited number of possible values. Continuous-valued data is most regularly numerical, or is composed of numerical data.
</t>
<t>Physical properties are a prime example of the use of continuous-valued data. Any value expressed in the SI units (metres, kilograms, seconds, ampere, kelvin, mole or candela) and units derived from these are within the general remit of this document.
</t>
<t><list style="hanging"><t hangText="Note:">For those with an interest in physics, this document does not concern itself with quantum effects. At the point that presence concerns itself with quantum physics, this document is most likely long redundant.
</t></list></t>
<t>Examples of continuous-valued presence elements could include descriptions of the physical characteristics of a presentity or its immediate environment. This could include position in space; weather related values such as ambient temperature and wind speed; light or noise intensity; remaining battery life of a device; weight and size.
</t>
<section title="Continuous and Discrete Values in Presence">
<t>In contrast, the many elements defined in <xref target="RFC4480">RFC 4480</xref> are all discrete-valued. Some of these discrete-valued presence elements are a product of an underlying continuous value. For instance, the <spanx style="verb">sphere</spanx> element is often derived from the location of the presentity.
</t>
<t>For many applications, the overall system is greatly simplified by the use of discrete-valued data. However, the means of derivation (or sampling) varies and can involve heuristics that might not be compatible with the needs of all watchers. Furthermore, the process can be subjective, requiring active user input. Access to uninterpreted continuous values allows for a wider range of applications.
</t>
</section>
<section title="Measurement">
<t>The act of determining a continuous value is an act of measurement. The value that is represented in a presence document is the product of a measurement process. All measurement processes are subject to measurement uncertainty, a well-documented phenomenom <xref target="ISO.GUM"/>.
</t>
<t>This document applies to the inclusion of continuous-valued data in presence, with any of the following constraints:
<list style="numbers">
<t>The process of measurement has non-zero—or at least non-negligible—cost. Cost can be defined in any number of ways, but could include time, processing resources, network utilisation, labour or financial.
</t>
<t>The measurement process has limited accuracy, resulting in uncertainty that is—or could be—significant.
</t>
</list>
Cost and accuracy are somewhat related. In general, improvements in one result in degradation of the other. For continuous-valued information that is not subject to these constraints, some requirements from this document could still apply.
</t>
<t>From the above constraints, one aim of any system that handles such continuous-valued data is to minimise both cost and uncertainty using different trade-offs. A common factor amoungst systems that handle continuous-valued data is the desire to be able to ignore the effects of these constraints. Where ignorance is not viable, systems exhibit a range of traits: iterative measurement collection, caching of results, fuzzy logic, maximum likelihood estimation and other forms of statistical analysis.
</t>
<t>A significant example of a continuously varying parameter is the position of an entity in space, or its location. Location information as an element of presence was established in <xref target="RFC4079"/> and a format specified in <xref target="RFC4119"/>. Uncertainty in location information, described in more detail in <xref target="I-D.thomson-geopriv-uncertainty"/>, is a product of the method of location generation used and can vary greatly; likewise, the amount of time required to ascertain location within specific quality constraints is highly variable.
</t>
</section>
<!--
<t><list style="empty">
<t>An astute reader will note that time was one of the continuous-valued elements described earlier. This document assumes that uncertainty in the measurement time is small enough that its effect can be ignored. This does not mean that time measurement is not important - sources of continuous-valued data need to measure and specify time with an accuracy appropriate to the intended use of the other data they provide.
</t>
<t>If uncertainty in the measurement of time is significant, it could either mean that presence is not appropriate for the use or that alternative means of expressing time need to be developed.
</t>
</list></t>
-->
</section>
<section title="Logical Model: Presence Sources">
<t>The entity that measures continuous-valued data—and the process of measurement—are crucial in determining the resulting information. <xref target="RFC3856">RFC 3856</xref> notes that presence data can be sourced by a variety of means, but does not attach any significance to the source of presence data. This document adopts a model that distinguishes between the PA and the presence source.
</t>
<figure anchor="logical" title="Logical Model">
<artwork><![CDATA[
+----------+ +----------+ +---------+
| Presence |_____________| Presence |______________| Watcher |
| Source | (Various) | Agent | (Presence) | |
+----------+ +----------+ +---------+
]]></artwork>
</figure>
<t>Specifics of the interaction between presence source and PA are out of scope for this document. There might be formalised protocols, or the PA might use unspecified or informal methods to acquire data. Formalised exchanges include <xref target="RFC3903">SIP PUBLISH</xref>; informal interactions include those that are briefly described in Section 7 of <xref target="RFC3856"/>.
</t>
<t>For location information, the <xref target="RFC3693">GEOPRIV architecture</xref> defines the Location Generator. The Location Generator is the presence source of this model; the entity that generates, or measures, the continuous value. In the GEOPRIV architecture the Location Server is the analogue of the PA and the Location Recipient corresponds to the Watcher. Other forms of continuous-valued data might have similarly formal architectures and nomenclature.
</t>
<t>In an end-to-end system, the model is potentially iterative. An entity that acts as a presence source to a PA could equally acquire its information from a separate source; from a different perspective, the PA becomes a watcher and the presence source becomes a PA. The discussion in this document concentrates on the simple model; a presence source in text generally refers to the ultimate presence source: the entity that performs measurement.
</t>
<figure anchor="iterative" title="Iterative Application of the Logical Model">
<artwork><![CDATA[
+----------+ +----------+ +---------+
| Presence | | Presence |____| Watcher |
| Source | | Agent | | |
+----------+ | - or - +----+ - or - | +---------+
| Presence |____| Presence | | Watcher |
| Source | | Agent | | |
+----------+ +----------+ +----------+
]]></artwork>
</figure>
<section title="The Role of the Presentity">
<t>As the subject of presence information, there are two main aspects to the presentities involvement in this model. The presentity can, in some circumstances, act as a presence source, even though the model does not require any direct involvement. More significantly, in all cases the presentity has the most significant stake in ensuring that it retains some measure of control over the process.
</t>
<t>The presentity exercises control over the dissemination of presence information through use of policy. Enforcement of policy is performed by the PA. Policy is used to restrict access to presence information in various ways, typically manifesting in limiting the information that is made available to watchers. This document describes requirements for policy that also limit what controls the watcher is given over the measurement of continuous-valued presence information.
</t>
<t><list style="hanging"><t hangText="Note:">The GEOPRIV model assigns the label of "Rule Maker" to the role assumed by the presentity when setting policy. The Rule Maker role is further extended to include other stakeholders. The requirements in this document do not preclude this abstraction.
</t></list></t>
<t>In some cases, a presentity also acts as a presence source. A presentity could exploit this confluence by restricting the information that it provides as a presence source, thereby obviating the need for certain aspects of policy. This can be an advantageous circumstance, particularly where the PA limits the complexity and size of the policy it accepts.
</t>
</section>
</section>
<section title="Problem Statement">
<t>Continuous-valued data cannot always be treated in the same fashion as discrete-valued data. This section outlines a number of considerations that distinguish continuous-valued data. These considerations affect how the presence system uses continuous-valued data.
</t>
<section title="Unguided Measurement">
<t>A presence source is responsible for the measurement of presence data. Unless the watcher is able to communicate preferences to the presence source, the process of measurement is unguided.
</t>
<t>In the event that a PA and watcher operate independently of the presence data source, there is a risk that continuous-valued data is measured inappropriately. Values might be measured too frequently or with unneeded degree of accuracy, that is, accuracy is favoured too highly over cost. Conversely, if cost is optimised, measurements might be insufficient in frequency or accuracy.
</t>
<t>Communicating watcher preferences to the presence source addresses this problem by making information about what the watcher wants available to the presence source. With this information the measurement process is no longer unguided.
</t>
<t>Communicating watcher preferences to the presence source is especially critical if the watcher also incurs costs relating to the measuring of the continuous value. The most direct cost is in time: the watcher might be forced to wait for measuring of information to an accuracy more stringent than needed. However, it need not be limited to time.
</t>
</section>
<section title="Presence Filters">
<t>It is possible to resolve the problem of unguided measurement without resorting to explicit protocol mechanisms. Presence filters (<xref target="RFC4660"/>, <xref target="RFC4661"/>) are a vessel for conveying a watcher's preferences to the PA. If the PA has a means of communicating with a presence source, it is able to request measurement of continuous-valued data according to the preferences it is aware of. By communicating the watcher's preferences in this manner, the presence source is able to measure accordingly. Additional changes to presence subscriptions (<xref target="I-D.niemi-sipping-event-throttle"/>) and filter extensions (<xref target="I-D.ietf-geopriv-loc-filters"/>) make more information available to the PA; this information could be passed on.
</t>
<t><xref target="pa-model"/> shows a simplified model of the existing system of filtering for presence data. The system assumes that presence information is perfect. If this is not the case, the only option for a PA is to project the illusion that this is the case. The only information available to the PA is to use the filter and throttling data available to it to limit the costs it incurs in retrieving information from sources.
</t>
<figure anchor="pa-model" title="Presence Agent Model">
<artwork><![CDATA[
+--------------------------------------------------------+
| Presence Agent (PA) |
| |
| ,---------------+<--------+<-------+<-------------
| / (Presentity / / / SUBSCRIBE |
| | Identifier) / / / |
| V | | | |
| ,----------. | | | |
| | | V | V |
| | Presence | \---------\ : \----------\ |
| | Master |--->) Filter )------->) Throttle )---------->
| | Data | /---------/ : /----------/ NOTIFY |
| | | | | / |
| `----------' | / / |
| ^ ^ ^ |,------+-------' |
| | | | / |
| .-+--+--+-. / |
| / Trigger \ <----' +----------+ |
| ^--+--+--+--^ | Internal | |
| | \ `-----------------------| Presence | |
| | `. | Source | |
| | `-. +----------+ |
| | `. |
+----+-----------+---------------------------------------+
| \
| `.
+----------+ +----------+
| Presence | | Presence |
| Source | | Source |
+----------+ +----------+
]]></artwork>
</figure>
</section>
<section title="Quality">
<t>Ensuring that a watcher is able to access information that meets their needs is an important goal of presence filters. When it comes to information quality, there are two separate goals that need to be distinguished:
<list style="symbols">
<t>A filter is used to determine when (and if) the PA notifies the watcher of changed presence information. This filter is usually strictly boolean, or "hard": unless the condition is met, no notification is generated.
</t>
<t>A target quality is used to inform the presence source (the measurement process) of the desired quality of the result. This target is "soft": if the stated quality cannot be provided, a notification might still be generated. In this way, this information acts as a goal for the presence source, rather than a condition on the notification process.
</t>
</list>
The difference between the soft target and hard filter could alternatively be characterised as "want" or "need". The concept of a soft target is not necessary for discrete-valued presence data. Indeed, treating this as a filter, a term which implies post-measurement application, is misleading.
</t>
<t><list style="empty"><t>Suppose a watcher, Bob, is watching the location of a presentity, Alice. Bob specifies a hard filter that specifies a maximum uncertainty of 50m. If this is used to advise the presence source, the source attempts to determine a location within that uncertainty. If the source is unable to meet the requirement, the filter ensures that no notification is sent to Bob.
</t>
<t>However, Bob could handle uncertainty of up to 1000m; it's not ideal, but some information is better than none. If he specified a larger constraint using the hard filter, the source might use cheaper methods that never produce a result with the accuracy Bob really wants. Therefore, Bob provides two values: a soft target of 50m, and a hard cutoff at 1000m uncertainty.
</t></list></t>
<t>From this example, it can be seen that soft quality preferences are useful where continuous-valued data is the subject. In comparison, the hard filter is not tolerant of variation in quality. The soft preferences are used to guide the measurement process, but aren't restrictive of the final result.
</t>
<t>Quality constraints can be used to ensure that cached data is not used. For instance, a constraint might be placed on the timestamp that forces the measurement of new data. This is discussed in more detail in <xref target="now"/>.
</t>
</section>
<section title="Watcher Feedback">
<t>A watcher requires adequate feedback from the PA about how its preferences are being acted upon. To a watcher, a PA that fully communicates watcher preferences to a presence source, remains indistinguishable from a PA that is either less able to acquire data (because it relies on <xref target="RFC3903">PUBLISH</xref>), or simply chooses not to perform this communication.
</t>
<t>In some cases, a watcher is able to compensate for any limitations imposed by the PA. As shown in <xref target="value-seek"/> adaptive polling can be used to seek a particular value. However, if a watcher uses polling for value-seeking, this potentially duplicates similar efforts from the PA or presence source.
</t>
<t>In other circumstances, shortcomings cannot be addressed by the watcher. For instance, perhaps the presence source is capable of providing information to a certain high degree of accuracy, but unless requested it does not do so (the cost is too high). If the PA never requests highly accurate information, that information is never available to the watcher.
</t>
<t>Providing the watcher feedback on what efforts the PA and presence source make to acquire information ensures that the watcher is able to avoid replicating behaviour. It also ensures that the watcher is able to make realistic requests.
</t>
</section>
<section title="Active and Passive Sources">
<t>For a particular presence datum, the means by which the PA is able to acquire updated information varies. For some forms of discrete-valued data—such as basic status—the PA might be considered absolutely authoritative, in that the information is absolutely correct by definition. Data can be made available to the PA either passively or actively:
<list style="hanging">
<t hangText="Passive Acquisition:">The PA is a passive recipient of updated information with no means to trigger measurement. <xref target="RFC3903">SIP PUBLISH</xref> is an example of how the PA could passively acquire data.
</t>
<t hangText="Active Acquisition:">The PA is able to seek updated information, and does so based on one or more triggers.
</t>
</list>
</t>
<t>Providing the watcher information on the nature of a particular presence source is an important part of the feedback provided by the PA. If the PA only passively acquires data, much of the considerations presented in this document become moot. More significantly, if the PA does not provide any options to the watcher to influence its interactions with the presence source, the same applies. Thus, it is when the PA provides some means of conveying watcher preferences to the presence source that active acquisition becomes useful.
</t>
<t><list style="empty"><t>Back to Bob and Alice: This time, Bob wants to know when Alice passes by the library where Bob works. Bob sets a filter, requesting that he only be notified when Alice passes within 100m of the library. If the PA passively receives updates about Alice's location from a presence source, it could be that it never receives information when Alice passes by—the presence source might not publish the necessary information at the crucial moment.
</t></list></t>
</section>
<section title="Triggering Measurement">
<t>Stimulating the generation of a value for the continuous variable can be done through several methods:
<list style="symbols">
<t>immediate or on-demand triggers</t>
<t>time-based or periodic triggers (polling)</t>
<t>value-based triggers</t>
</list>
</t>
<section anchor="now" title="Immediate Triggering of Measurement">
<t>An immediate request for measurement provides the simplest means of directly providing the presence source with necessary information. A watcher makes a request to the PA, including its preferences. The PA then acquires information from the presence source, passing watcher preferences directly to the source.
</t>
<t>An immediate request for updated information is particularly useful where information is cached at one or more intermediaries. Caching is a tool that is widely used in protecting resources where multiple watchers require access to the same information. After a presence datum is acquired, requests within a set period are served from a cache to reduce the time required to serve the request and to avoid the costs in gathering the data.
</t>
<t><list style="empty"><t>In presence, the first cache is usually the watcher user agent, which maintains a cached presence document for each presentity. This cache is updated when the PA notifies the watcher of changes.</t></list></t>
<t>Caching behaviour can interfere with certain use cases, particularly those where currency of information is valued over efficiency. For instance, if a watcher wants to know what the ocean temperature off the coast of Madagascar is <spanx style="emph">now</spanx>; if hour-old data is not useful, a caching mechanism could interfere with that goal. Thus, a degree of cache circumvention is a necessary mechanism.
</t>
<t>The simplest mechanism for avoiding cached data is to specify a quality constraint that limits the age of information. Setting this age value to zero indicates to any caching entity that old information is no good. As long as the caching policy allows it, the cache is avoided. Values larger than zero indicate how old the cached information can be to be used. This ensures that the benefits of caching are achieved without negative affecting the watcher.
</t>
<section title="Immediate SIP SUBSCRIBE">
<t>For SIP presence, the means of triggering immediate measurement is the SUBSCRIBE request. This presents a challenge for the SIP presence framework if the presence source is not able to provide the requested information immediately. <xref target="RFC3265">RFC 3265</xref> states:
<list style="empty">
<t>When a SUBSCRIBE request is answered with a 200-class response, the notifier MUST immediately construct and send a NOTIFY request to the subscriber.
</t></list></t>
<t>If the PA is unable to provide an immediate notification due to lack of information, it must indicate this to the watcher. A presence document might be a composit of continuous- and discrete-valued data. Any solution for continuous-valued data cannot affect the conveyance of discrete-valued data. Compatibility with existing the existing presence framework is also desirable. Therefore, an immediate notification is still necessary.
</t>
<t>Some time after the initial request, when the continuous-valued data becomes available, a second notification can be sent. However, another conflict arises with event rate throttling. When information becomes available, the notification might be suppressed due to a short elapsed time since the initial notification.
</t>
<t>Any means of triggering immediate measurement needs to consider these problems.
</t>
</section>
</section>
<section title="Periodic Triggering of Measurement">
<t>Periodic notifications of the value of presence data are not assumed to be necessary by the existing work. Values are assumed to change infrequently, or if frequent changes are necessary, solutions have concentrated on means of throttling notifications. <xref target="RFC3265">RFC 3265</xref> recommends that event packages specify a minimum interval between notifications; and <xref target="I-D.niemi-sipping-event-throttle"/> provides a direct means of controlling this interval.
</t>
<t>If the watcher has an interest in the value of a particular datum over time, it is useful to be able to have the PA provide notifications at regular intervals.
</t>
<t>A similar time-based problem exists for periodic notification as did for the immediate request. The PA cannot request presence information at the time that a notification is required—the presence source is unlikely to be able to produce a result so quickly. The PA needs to allow the presence source sufficient time to make a measurement. This time can be allocated before the notification is required so that all the necessary data is available for the notification.
</t>
<t>Deciding how much time to allow the presence source for measurement presents another problem. Relying upon a value specified by the watcher ensures that the measurement process is guided appropriately.
</t>
<!--
<t>In one alternative solution, the entire period between notifications can be allowed; however, this could be wasteful. Depending on the nature of the interface between PA and presence source, the request might be such that the presence source starts measurement immediately when request. Given long enough the presence source could produce a result a long time before the indicated time. Providing large amounts of time could also result in the use of unnecessarily lengthy measurement processes.
</t>
-->
</section>
<section anchor="value-seek" title="Value-based Triggering of Measurement">
<t>A watcher might only be interested in a value if that value enters a particular range. For instance, for location, the watcher might be interested when the presentity is in the vicinity of a particular landmark, or even the when two presentities approach each other. A watcher that monitors the temperature of a presentity might be interested if the temperature exceeds a certain threshold.
</t>
<t>Value-seeking can be performed in different ways. Given certain assumptions or knowledge about the rate of change of a value and the desired responsiveness, an adaptive polling method can be used. The rate of polling can increase in frequency in proportion to the proximity of the current value to the target range. In addition, time and quality constraints can be relaxed or made more stringent as appropriate. The advantage of polling is that it can be performed based on the value only. The additional knowledge available to a presence source is not necessary; a PA or watcher is able to use polling for value-seeking.
</t>
<t>A presence source can potentially use alternative information to assist in value-seeking. For data that is derived from other measurements, the value of the unprocessed measurements might provide an adequate indication of the value to obviate any need to continue measurement. For instance, the set of wireless transmitters that can be observed by a wireless device can be used as a rough indication of location.
</t>
<t>Value-seeking can be of great benefit to applications, particularly for simplifying the application logic. Without this feature, an application needs accept and interpret notifications and check values against a target range. As demonstrated in <xref target="I-D.thomson-geopriv-uncertainty"/>, this can be non-trivial. If a trigger can be set based on a certain value, the notification provided by the PA indicates that the condition has been met.
</t>
<t><list style="empty">
<t>Lee is a surfer. He uses a presence service to inform him of when the waves are good at his favourite beaches. During the week, when Lee is usually at work, Lee sets a trigger that notifies him when the waves reach a certain size at any one of these beaches. If the waves reach the size that means that surfing becomes a higher priority than working, Lee is sent a text message. Upon receiving the text message, he drops what he is doing to catch the big surf.
</t>
<t>This case can also be used to demonstrate one reason for using continuous-valued data instead of discrete-valued data. Harriette might also be an equally keen surfer, but less flexible employment. She has to set a more stringent set of criteria before she is willing to renege on her responsibilities. Giving both surfers access to the raw data lets them set their own definition for what is worth skipping out on work. Any discrete value that is assigned reflects a certain set of values that cannot be universally accurate.
</t>
</list></t>
</section>
</section>
</section>
<section title="Requirements">
<t>The requirements documented in this section relate to subscriptions for continuous-valued data. These requirements do not make any assumptions about the nature of the relationship between PA and presence source. A presence source is assumed to be present only to the extent that the measurement of a particular presence element affects the results observed by the watcher.
</t>
<t>A solution that addresses these requirements MAY address them based on a specific type of data. Some requirements might not suit a generic solution.
</t>
<section title="Quality Requirements">
<t><list style="format Q%d.">
<t>The system MUST provide a watcher the ability to express non-binding requirements on information quality for continuous-valued presence data.
<vspace blankLines="1"/>
Motivation: Having a means to express preferences in non-binding fashion can have the desired effect in influencing the measurement process at the presence source without other side-effects.
</t>
<t>The system MUST provide a means to indicate how information quality preferences are used or propagated.
<vspace blankLines="1"/>
Motivation: Providing adequate feedback to a watcher assists the watcher in making decisions about its behaviour. From the perspective of a PA, this requirement can only be fulfilled based on the knowledge it has available. A PA can know whether or not it is the presence source, but it cannot assume that the entity it requests information from is the ultimate source of the information; a PA needs to—in turn—rely on the information provided by its source. This ensures that a watcher is able to learn how its preferences are getting to the ultimate source.
<vspace blankLines="1"/>
For instance, the PA or presence source might limit the extent to which quality parameters are able to bypass caches. This information can be integrated with any inherent limitations indicated by the source, or the mechanism used to acquire the presence data.
</t>
</list></t>
</section>
<section title="Immediate Triggering Requirements">
<t><list style="format IT%d.">
<t>The system MUST provide a means for a watcher to explicitly and immediately request measurement of a specified continuous-valued datum, bypassing any cached data.
<vspace blankLines="1"/>
Motivation: A direct request for data ensures that the presence source is properly advised of the constraints of a request. It also ensures that a watcher has access to updated information.
</t>
<t>The system MUST provide a means for the watcher to communicate time constraints on the measurement process.
<vspace blankLines="1"/>
Motivation: Specifying time constraints ensures that the information is available to the watcher when required. It also ensures that the presence source applies appropriate methods in measuring.
</t>
<t>The system MUST provide a means for a PA to limit support for immediate requests.
<vspace blankLines="1"/>
Motivation: Making a direct request to the presence source increases the load on the presence source and PA. A PA implementation might want to constrain access to immediate requests to prevent denial of service.
</t>
<t>The system MUST provide a means for a PA to indicate support for immediate requests, including any limits or constraints on that support.
<vspace blankLines="1"/>
Motivation: Providing adequate feedback to the watcher ensures that the watcher is able to modify its behaviour accordingly.
</t>
</list></t>
</section>
<section title="Periodic Triggering Requirements">
<t><list style="format PT%d.">
<t>The system MUST provide a means to request periodic measurement of a continuous-valued datum at a specified interval.
<vspace blankLines="1"/>
Motivation: Periodic measurement is the most basic means of enabling tracking of a value over time. More sophisticated methods might be used, but this sets a minimum level of capability that can be exploited for any type of continuous-valued data.
</t>
<t>The system MUST provide a means for a PA to limit support for periodic requests.
<vspace blankLines="1"/>
Motivation: Excessive polling rates might result in denial of service through excessive requests.
</t>
<t>The system MUST provide a means for a PA to indicate support for periodic measurement, including any limits or constraints.
</t>
<t>The system MUST provide a means for a watcher to explicitly limit the rate of notifications.
<vspace blankLines="1"/>
Motivation: Even without perfect information, the defining characteristic of continuous variables is the potential for continuous change. This manifests in presence as a continuous stream of data from the PA to the watcher. For a range of reasons—protection of network utilization not-withstanding—this is not desirable.
<vspace blankLines="1"/>
References: <xref target="I-D.niemi-sipping-event-throttle"/>
</t>
</list></t>
</section>
<section title="Value-Seeking Requirements">
<t><list style="format VT%d.">
<t>The system MAY provide a means for a watcher to indicate a particular range of values to seek.
<vspace blankLines="1"/>
Motivation: If a watcher is only interested in a certain range of values, limiting measurement and notification protects resources on both the presence source and watcher.
</t>
<t>The system MUST provide a means for a PA to indicate support for value-seeking requests, including any limits or constraints on that support.
<vspace blankLines="1"/>
Motivation: Providing adequate feedback to the watcher ensures that the watcher is able to modify its behaviour accordingly.
</t>
</list></t>
</section>
<section title="Timeliness Requirements">
<t><list style="format T%d.">
<t>Continuous-valued data MUST always have a timestamp that indicates when the value was measured.
<vspace blankLines="1"/>
Motivation: A continuously varying datum is, by its nature, inevitably out of date at the time that the watcher receives it. In practice, this is only a problem if the time between measurement and receipt of the data is large. Since this is a matter of degree, providing a timestamp ensures that a watcher is able to make a judgment about validity.
<vspace blankLines="1"/>
If time information is not included, the recipient of continuous-valued information has no means of judging how current the information is. <xref target="RFC3863">PIDF</xref> specifies a <spanx style="verb">timestamp</spanx> element, which is optional, but is described as being necessary if available. This requirement makes the value mandatory.
<vspace blankLines="1"/>
The corollary to this that an item of continuous-valued data is automatically invalid if it is not timestamped.
</t>
<t>The system MUST provide a watcher the ability to limit the age of data that it is provided.
<vspace blankLines="1"/>
Motivation: This ensures that caching of data is only used to the extent that it is acceptable to the watcher.
<vspace blankLines="1"/>
References: <xref target="I-D.thomson-geopriv-location-quality"/>, Requirement IT1.
</t>
<t>The system SHOULD provide a means for a watcher to indicate how long measurement of continuous-valued data is allowed to take.
<vspace blankLines="1"/>
Motivation: This indication assists the PA and presence source in making decisions about how much time to allocate to measurement; for periodic measurement, it provides a hint on when to start measurement. This guidance is often better served by other quality constraints in situations where the delay is not evident to the watcher. However, a time-based value serves in a wide range of scenarios and guides behaviour where a PA might not understand the quality constraints specific to a data type.
</t>
</list></t>
</section>
<section anchor="privacy" title="Privacy Requirements">
<t><list style="format P%d.">
<t>The system MUST provide a means for a presentity (rule maker) to control how watchers are able to request continuous-valued data.
<vspace blankLines="1"/>
Motivation: A presence agent acts for the presentity in disseminating presence information. Policy is the primary means of privacy control available a presentity.
<vspace blankLines="1"/>
Many of the requirements in this document describe more flexible means of acquiring presence information. Policy provides a means for a presentity to limit a watcher's access to these features and thereby restrict access to private data.
<vspace blankLines="1"/>
References: <xref target="RFC4745"/>
</t>
</list></t>
<t>Each of the individual aspects of watcher-agent-source interaction are appropriate subjects for policy:
<list style="hanging">
<t hangText="Quality:">A presentity might want to limit the quality of the information provided. Quality can be purposefully degraded post-measurement. If this restriction is known before measurement, the presence source might be able to avoid some costs in generation.
</t>
<t hangText="Immediate Triggers:">A presentity might want to restrict access to immediate requests, or force the use of cached data.
</t>
<t hangText="Periodic Triggers:">A presentity might want to prevent periodic requesting, or place a limit on the rate that can be requested by watchers.
</t>
</list>
Each of the mechanisms that allow for greater control at the watcher MUST also consider policy controls to limit or block use of that mechanism. This guarantees that a presentity (or rule maker) is able to communicate appropriate rules to the PA.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>A number of requirements involve a PA making information about its operation available to a watcher. This information might be consider sensitive by the operators of a PA. Any solution that addresses these requirements MUST provide an option to suppress this information and MAY include guidance on when this might be appropriate.
</t>
<t>Many of the requirements in this document potentially result in PA and presence source behaviour being controlled to some extent by a watcher. A malicious watcher could attempt a denial of service attack by exploiting the fact that some of this behaviour requires greater expenditure resources from the PA and presence source than is incurred in making the request. In particular, periodic requests or requests that includes value-seeking require significant processing in response to a relatively simple request. Any solution that addresses these requirements MUST consider the implications of denial of service on the PA and SHOULD also consider the presence source.
</t>
<t>Caching of results can limit the load imposed by multiple requests for the same information. To protect against denial of service, a PA MAY choose to suppress any options for bypassing cached data.
</t>
<t>Privacy is a major consideration in any architecture that defines more flexible means of access to private data. <xref target="privacy"/> describes requirements that are aimed at providing a presentity (or other rule maker) greater control over the access watchers have to private data. These focus on the application of policies that direct the actions of the PA.
</t>
</section>
<section title="Acknowledgements">
<t>This document is a clumsy attempt to formalize the output of discussions on the nature of presence and its applicability to location information. Adam Roach has been helpful in destroying misconceptions about presence. Jonathan Rosenberg pointed out a major omission in an early version of this document ignoring the role of the presentity. Thanks also to Richard Barnes, Jon Peterson, Robert Sparks, James Winterbottom.
</t>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC2778;
&RFC3265;
&RFC3693;
&RFC3856;
&RFC3863;
&RFC3903;
&RFC4079;
&RFC4119;
&RFC4480;
&RFC4660;
&RFC4661;
&RFC4745;
&I-D.ietf-geopriv-lbyr-requirements;
&I-D.ietf-geopriv-loc-filters;
&I-D.garcia-simple-indirect-presence-publish;
&I-D.niemi-sipping-event-throttle;
&I-D.thomson-geopriv-uncertainty;
&I-D.thomson-geopriv-location-quality;
<reference anchor="ISO.GUM">
<front>
<title>
Guide to the expression of uncertainty in measurement (GUM)
</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="1995"/>
</front>
<seriesInfo name="Guide" value="98:1995"/>
</reference>
</references>
<section title="Presence Agent and Source Interactions">
<t>[[Ed: this section has some informational value, but need to determine how much that contributes to the document.]]</t>
<t>This document specifies requirements that expose the nature of the association between PA and presence source. While there are no direct requirements on this interface and proprietary solutions are entirely appropriate, it is hoped that these requirements will influence the design of any protocol mechanisms used on this interface.
</t>
<t>Associations between PA and presence sources could be largely static in nature, as is true of the methods described in <xref target="RFC3856"/>. Establishing dynamic associations between PA and presence source is an option where disparate presence sources are required. This is especially true for location information, where close physical proximity between presentity and source is usually required; consequently the presence source can dynamically change as the presentity moves.
</t>
<t><xref target="I-D.ietf-geopriv-lbyr-requirements">Location by-reference</xref> provides a means whereby a relationship between any entity and the Location Generator can be established. By contacting the Location Generator, a requester is able to specify preferences for how location information is generated/measured. A location reference forms the basis for establishing an association between Location Generator and a Location Server.
</t>
<t>For presence, <xref target="I-D.garcia-simple-indirect-presence-publish">Indirect publish</xref> describes how a PA is able to use the indirection provided by a URI. The URI is used to establish a link between the generator of presence information and the PA. The URI is distinguished by two characteristics:
<list style="symbols">
<t>the host serving the URI is the presence source
</t>
<t>additional information in the URI provides enough information to uniquely identify the presentity to the presence source
</t>
</list>
</t>
</section>
<!--
<t><list style="empty">
<t>Consider a system that measures the proportion of sulphur in petroleum that flows through a pipeline. Measurement requires the taking of a small sample and subjecting that sample to a test. Variability in samples mean that multiple measurements are required over time. In the absence of information about when results are required, the rate at which sulphur analyser takes samples is uncontrolled. The cost of continuously taking samples might be prohibitive, but infrequent sampling could mean that crucial data is unavailable when needed.
</t>
<t>Futhermore, multiple methods are available for sulphur analysis and each method has different characteristics regarding accuracy and cost. If the consumer of the information could have varying requirements, it is not possible to select an appropriate method ahead of time.
</t>
</list></t>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:25 |