One document matched: draft-schulzrinne-simple-composition-01.txt
Differences from draft-schulzrinne-simple-composition-00.txt
SIMPLE H. Schulzrinne
Internet-Draft R. Shacham
Expires: September 6, 2006 Columbia University
W. Kellerer
S. Thakolsri
DoCoMo Eurolabs
March 5, 2006
Composing Presence Information
draft-schulzrinne-simple-composition-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Composition creates a presence document from multiple components
published by one or more sources. This document identifies sources
of information that a composer might draw upon and describes steps
for composition. The composing function can be complex, so we
intentionally restrict the discussion to cases that are likely to be
Schulzrinne, et al. Expires September 6, 2006 [Page 1]
Internet-Draft Composition March 2006
common across many users of presence systems. We present an XML
format for specifying a composition policy, based on our discussion.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scoping Composition . . . . . . . . . . . . . . . . . . . . . 4
3. Types of Information sources . . . . . . . . . . . . . . . . . 5
4. Discarding . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Deriving Presence Information . . . . . . . . . . . . . . . . 7
6. Information conflict . . . . . . . . . . . . . . . . . . . . . 9
6.1. Sources of Information Conflict . . . . . . . . . . . . . 9
6.2. Detecting information conflicts . . . . . . . . . . . . . 10
6.3. Resolving Information Conflicts . . . . . . . . . . . . . 11
7. Tuple Merging . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Service tuples . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Person tuples . . . . . . . . . . . . . . . . . . . . . . 13
8. Default Policy . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Composition Policy Format . . . . . . . . . . . . . . . . . . 14
9.1. Discard step . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Derive step . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. Resolve Conflicts Step . . . . . . . . . . . . . . . . . . 15
9.4. Merge Step . . . . . . . . . . . . . . . . . . . . . . . . 16
10. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Schulzrinne, et al. Expires September 6, 2006 [Page 2]
Internet-Draft Composition March 2006
1. Introduction
Composition combines multiple presence or event sources into one
view, which is then delivered, after various filtering operations, to
watchers [6] [7]. Composition is required whenever there are several
sources contributing information about a single presentity or event.
[Note: The content in this draft overlaps with the Processing Model
draft and needs to be reconciled. Here, the emphasis is on
developing the foundations for a composition policy language, and
deal with merging <person> tuples.]
For notational simplicity and since most of the discussion has
focused on presence rather than general events, we will restrict our
attention to presence information using the Presence Information Data
Format (PIDF) [3] and extensions such as the Rich Presence
Information Data format (RPID) [4], keeping in mind that other types
of events or status may well be able to use many of the same
mechanisms. We assume that a presentity is a single human being.
There are other presentities, such as the collection of customer
service agents in a call center, where consistency is much harder to
define.
We assume that the composition operation does not depend on the
watcher identity, as there seems little functional gain by
introducing per-watcher composing operations. The composed document
contains the maximum set of information, i.e., no watcher can obtain
more information than is contained in the composed raw presence
document. (In some cases, a presentity wants to "polite block" a
person by providing presence information that offers no information
to the watcher, but avoids indicating that the watcher's subscription
request has either not yet been processed or that it has been turned
down. For those cases, a simple template that reflects a minimal
PIDF document is sufficient, as it does not need to reflect presence
inputs and does not change over time.)
Composition at the presence agent is just one component of providing
useful and correct information to the watcher. We assume that
composition is algorithmic, although manual composition by the
presentity is theoretically possible. Given the automated nature of
composition, there may well be situations where the best course of
action is to expose the underlying data to the watcher, even though
it may be contradictory. Indeed, in many cases, a mechanical
composer may not even be able to detect whether information is
contradictory or not.
The goals of composition are to remove information that is either
stale, contradictory or redundant, to generate inferred presence
Schulzrinne, et al. Expires September 6, 2006 [Page 3]
Internet-Draft Composition March 2006
state and to represent presence information in a more useful way.
Stale information has been superseded by other, newer information.
Contradictory information makes two statements about the presentity
that cannot both be true. Redundant presence information provides
information that is no longer of interest. For example, a presentity
may decide to drop information about services whose status is closed
if there are open services and may drop a service record referring to
another person via a <relationship> element if the presentity itself
is available. Inferred presence state uses presence elements or
external information to derive new information. Location information
seems particularly suitable for such inferences. For example, a
location away from home might generate the activity indication 'away'
or specific geospatial locations might be mapped to particular
location types or activities. Presence information may be presented
in a useful manner by merging non-contradictory information or by
dividing up services based on a common attribute.
Composition is not designed to reduce the size of notification
messages or to protect information for privacy. Various compression
schemes and partial notification [10] are better suited to reduce
message sizes. Privacy filtering [8] has the role of tailoring
information to individual recipients, based on the presentity's
privacy policy.
In our model, the composer is reactive. In other words, it only
creates a new presence document if one of the publishers updates
parts of the presence document. An active composer could, for
example, generate a new presence document after a certain time
interval has elapsed or when timed presence [5] information is
transitioning from the future to the present.
The goal of this document is to outline options and then to derive a
composition policy language that allows the user to control the steps
that produce his presence document according to the aforementioned
goals. Alternatively, a presence composition language can focus on
the XML document and its components. Such a general presence
composition language would have to be a full programming language, as
it would need to support standard programming constructs such as
conditionals, operations on XML elements in a document object model,
history and external sources. This document focuses on content-aware
policies rather than simple tools for mechanical transformations of
XML presence documents.
2. Scoping Composition
In our model, presence takes a presence document, made up of a set of
<tuple>, <person> and <device> tuples, each tuple consisting of one
Schulzrinne, et al. Expires September 6, 2006 [Page 4]
Internet-Draft Composition March 2006
or more elements, and creates another valid presence document based
on this information. Based on the aforementioned goals of removing
stale, contradictory or reduntant information, while providing
additional useful data and representing the information in a useful
manner, our model includes a sequence of operations on the input
tuples. These operations are: discarding, derivation, conflict
resolution and merging. Discarding tuples removes stale and
redundant information. Derivation provides useful new data.
Conflict resolution removes contradictory information. Merging
presents the presence in a useful manner.
Composition involves adding or removing information from a set of
sources, and this may be done at a tuple or element granularity.
Some of the steps operate at one granularity or another. While any
of the operations may be done on any tuple type, some operations may
be more likely performed on certain types. This information is
summarized in Table 1. Each of the steps is listed, along with the
granularity on which it typically operates, and whether it is likely
or unlikely to be used for each of the tuple types. The specific
elements in the table will be discussed in later sections.
+------------------+----------------+----------+---------+----------+
| Operation | granularity | <person> | <tuple> | <device> |
+------------------+----------------+----------+---------+----------+
| Discarding | tuple | likely | likely | likely |
| Derivation | element | likely | likely | likely |
| Conflict | tuple or | likely | likely | unlikely |
| Resolution | element | | | |
| Merging | element | likely | likely | unlikely |
+------------------+----------------+----------+---------+----------+
Table 1
Some elements can contain timing information indicating the range of
time that the information is believed to be valid. It is probably
not a good idea to combine elements that cover different, although
maybe overlapping, time intervals.
3. Types of Information sources
Presence information can be contributed by many different sources,
either directly, by publishers using PUBLISH requests or by a
presence agent acting as a watcher receiving NOTIFY requests. We
describe each mode of delivery operation in the following. In direct
mode, the composer has direct access, without presence protocol
mediation, to this information, e.g., via REGISTER requests or
layer-2 operations or access to user keyboard activity. Secondly,
Schulzrinne, et al. Expires September 6, 2006 [Page 5]
Internet-Draft Composition March 2006
sources can use SIP PUBLISH requests to update presence information.
Finally, presence agents can in turn subscribe to presence
information and receive NOTIFY requests. However, the mechanism of
data delivery is likely to be less important than the original data
source and how the information was derived. Thus, to the extent
possible, information about the original source should be preserved
as otherwise information might become more credible simply because it
has been re-published. We focus here on the semantic source of the
data, i.e., how it was derived, not how it was injected into the
presence system.
For simplicity, we do not try to assess the veracity of the presence
document. In order to evaluate the usefulness of a presence
document, we only care whether the presentity would want the
information to appear that way, not whether this corresponds to
observable facts. Thus, a presence document is correct in that sense
if it indicates that the presentity is in a meeting even though the
presentity has actually gone fishing if the presentity would like the
rest of the world to believe that he is at work. It may, however,
well be the case that composition policies find it easier to maintain
the truth than keep lies consistent across sources of presence
information.
We can distinguish the following sources of presence data:
Reported current: Reported current information has been provided by
the presentity within processing time delays of the current time.
A presentity can update status information manually, by setting
any of the element in a presence document. This update may be
made by sending a PUBLISH request, by using XCAP as specified in
[12] , or by a more direct update, such as editing it in a web
GUI. We assume that this information is correct when entered, but
the trustworthiness of the information is likely to decay as time
goes on, given that most human users will find it difficult to
continuously keep presence information up-to-date.
Reported scheduled: For reported scheduled information, a presentity
indicates its plans for the future rather than the present, e.g.,
in a calendar. The reliability of this information depends
largely on the diligence of the user in updating calendars and
similar sources.
Measured device information: Measured device information uses
observed user behavior on communication devices, such as the act
of placing or receiving calls or typing. The main source of error
is that a device may not be able to tell whether the presentity
itself is using the device or some other person.
Schulzrinne, et al. Expires September 6, 2006 [Page 6]
Internet-Draft Composition March 2006
Measured by sensors: Presence information measured by sensors
reflects the status of the presentity, e.g., its location, type of
location, activity or other environmental factors. Examples of
sensors include Global Positioning System (GPS) information for
location or a BlueTooth beacon that announces the type of
location, such as "theater", a person finds itself in. Sensors
have the advantage that they do not rely on humans to keep the
information up-to-date, but sensors are naturally subject to
measurement errors. In particular, in quantum mechanical fashion,
it is sometimes difficult to ascertain both the measured variable
and the identity of the presentity. For example, a passive
infrared sensor (PIR) can detect that somebody is in the office of
the presentity, but cannot detect whether this is the presentity
himself, cleaning staff or a dog. A GPS sensor cannot detect
whether the cell phone is being used by the presentity or has been
borrowed by the presentity's spouse.
Derived: Presence information might be derived indirectly from other
sources of data. For example, the basic open/closed status might
be algorithmically derived from a variety of other, watcher-
visible or not, elements.
4. Discarding
Whole tuples may be discarded based on one of the criteria below:
Closed contacts: All <tuple>s with a basic status of 'closed'. It is
generally appropriate to also delete the associated <person>
information, since it is meant to convey availability for a mode
communication which is now being taken away.
Old tuples: Tuples with a timestamp or time range older than a given
threshold are discarded. This may apply to <person>, <tuple>, or
<device> tuples.
Unreferenced tuples: <device> tuples that are not referenced by any
service <tuple>. (It should be noted that user activity
information about these devices may still be useful even if the
device itself is not part of any published service.)
5. Deriving Presence Information
New presence information may be created based on existing data. This
process, called presence derivation, takes presence data as input and
results in new presence data being included in the document. Certain
presence sources may not be capable of publishing all relevant
information, and users may sometimes not update all information that
requires their input.
Schulzrinne, et al. Expires September 6, 2006 [Page 7]
Internet-Draft Composition March 2006
Derivation of new information makes it easier to identify a conflict
with another presence source. For example, filling in the location
of a device that is incapable of publishing it for itself shows that
two of the user's services are on devices that are far from each
other. It can also provide information to the watcher indicating
communication capability that may not otherwise be known. For
example, a user's mobile device may easily be able to identify and
publish that it is in a car. However, more relevant information for
the watcher is that the user is driving, which may be derived if this
is usually true when the user is in a car (possibly during certain
times, such as weekday mornings and evenings). The user may also
wish to indicate that when he is "on-the-phone", this means that he
is "busy" and shouldn't be called except in an emergency. The user
may know that a specific place does not allow for private
communications, and he may automatically supplement his location
information with privacy information. More complex rules could be
derived that involve outside information such as time of day. For
example, when user-input is "idle" between certain hours of the
night, the user's activity should be set to "sleeping".
Derivation may be dynamic or static. Dynamic derivation, as in the
above cases, is done based on changing information, such as the
presentity's place type. This type of derivation only adds
information under certain circumstances. Static derivation adds
information that is always present because it is based on constant
information. For example, a device may not be able to publish RPID
extensions, but the capabilities of it and its associated service
could be included through derivation. This would be done by treating
only the contact address or device-id as the derivation input (for a
service or device, respectively), and all new information as the
result. Location information may also be added to tuples
representing stationary devices, such as IP phones, that do not
support the GEOPRIV extensions. A derivation may be specified to add
location information to a service <tuple> that has the device-id of a
known device. Since location is one of the most reliable ways to
perform conflict resolutions, the derived information may allow the
determination that the user is not available on that device, since
his cellphone reports him elsewhere. [It should be noted that [6]
discourages the inclusion of location information in the service
<tuple>. The function described above should be made possible in a
way that conforms with that document. An alternative is to create a
new <person> tuple containing the location, and associating it with
the service tuple.]
There is another way that this static information can be
supplemented. The XCAP mechanism described in [12] is used for
updating a user's presence. XCAP does not manipulate the user's
complete presence document, but, rather, a single presence document
Schulzrinne, et al. Expires September 6, 2006 [Page 8]
Internet-Draft Composition March 2006
which is one of the sources input to the compositor, along with
information sent by other presence sources, through PUBLISH or event
notifications. XCAP may be used to create <tuple> and <device>
tuples containing static information about the service or device.
During the composition process, multiple reports for a single service
(those containing identical <contact>s) and for a single device
(those <device> tuples containing identical <device-ID>s) are merged
together. If no identical <tuple> or <device> tuple has been
received from any other source, the static tuple will appear in the
resulting raw presence document. If there is another identical
tuple, the static and dynamic elements will be merged into a single
tuple. The <basic> status of any service appearing in the XCAP
document should be "closed" so that this becomes the default status
and, when the service is published by another source with a status of
"open", the resulting status will be "open", which is the union of
the two.
6. Information conflict
6.1. Sources of Information Conflict
Information conflict occurs when multiple sources give different
views of the presentity, some of which may be outdated or incorrect.
Information can be incorrect for any number of reasons, but some
examples include:
Location divergence: The publisher collecting the information may not
be colocated with the presentity at this particular time. For
example, Alice's home PC may report that the user is idle (not
typing), but Alice is using the office PC.
Update diligence: Some sources, particularly those updated manually,
are prone to only approximate reality. For example, few users
record all appointments or meetings in their calendar or,
conversely, remove all canceled meetings. This is particularly
true for regularly scheduled activities such as meals or commute
times.
Sensor failure: Sources that report their information differentially
are subject to silence ambiguity. If such a source does not
report new data, the receiver cannot tell whether the sensor is
malfunctioning or whether the information last received is still
current. This can be partially mitigated by requiring sources to
report when they are no longer confident of the data. However,
this does not deal with sudden source failures. Thus, some form
of keep-alive mechanism may well be needed that overrides
differential notification mechanisms. Even with keep-alive, there
is likely to be a substantial period of time between source
failure and failure detection, causing stale information.
Schulzrinne, et al. Expires September 6, 2006 [Page 9]
Internet-Draft Composition March 2006
6.2. Detecting information conflicts
We would like to be able to detect information conflicts, so that
appropriate processing logic can remove inaccurate information.
Information conflicts can be classified as to whether they are
detectable in a single element or only across elements and how easy
it is to detect them.
We distinguish single-element from multi-element conflicts. Single-
element conflicts occur if two elements, say <activities> in RPID, in
two sources cannot both be true or are highly unlikely to be true,
without having to inspect any other element. A multi-element
conflict occurs if only the combination of multiple elements
indicates a conflict.
Multi-element conflicts often have location, and properties known for
this location, as the common element. For example, certain
geospatial locations are known not to contain certain types of
places. Thus, both the location and the <place-type> information
are, by themselves, each credible and possible, but are detectably
wrong once considered together. These conflicts can be detected if
location or time can be mapped to reliable information from external
sources. As mentioned above, derived information can often make a
multi-element conflict into a single-element conflict by
supplementing information, and thus make conflict detection easier.
We distinguish three types of information conflict: obvious, probable
and undetectable, described in turn below.
For some pieces of presence information, information conflicts are
obvious and readily detectable. For example, under the one-person-
per-presentity assumption and common assumptions of physics, a single
presentity can only be in one place at a time. Thus, if two sources
report location information that differs by more than the margin of
error, one must be wrong. In RPID, the <place-is>, <privacy>,
<relationship>, <time-offset>, and <user-input> elements have
exlusive values, although in some cases, below the element level.
For example, the <privacy> field has information for both audio and
video, and thus two sources may report different information for
<privacy> and still both be correct as long as they refer to
different media types.
For other types of information, an automaton can guess with some
probability that two sources of information contradict each other,
but this may well depend on the values themselves. For example, the
<activities> combination of
away, appointment, in-transit, meeting, on-the-phone, steering
Schulzrinne, et al. Expires September 6, 2006 [Page 10]
Internet-Draft Composition March 2006
incrementally reported by different sources may well reflect the
activity of the typical Wall Street commuter in the Lincoln Tunnel,
speaking on his cell phone. One would hope, however, that
combinations such as "steering, sleeping" are rarely true, although
"sleeping, meeting" indicates that there are few activities that
completely rule out others. The <place-type> element is another one
that may take different values that are sometimes, but not always,
contradictory. For example, while "automobile" and "office" are
distinct values, "outdoors" and "stadium" differ only in their
specificity. For the types of elements that may or may not be
contradictory, two options seem possible. A table may be constructed
with each value in both a separate row and a separate column, so that
their relationships may be charted. The relationship of value A to B
may be contradictory, more specific, less specific, or no
relationship. Alternatively, different values may always be treated
as contradictory. The latter approach seems better suited for an
element like <place-type> where a single source is likely to have all
relevant information and can be fully accurate by itself. However,
this works less effectively for <activity>, for instance, where
different sources inherently give different types of information.
For example, a cell-phone says that the user is "on-the-phone", a
sensor says the user is "steering", and a calendar says that the user
is in a "meeting". It should be noted that even these RFID elements
may not serve as good indications of conflict between tuples.
Differences in location, as mentioned above, is likely to be a much
more effective means, albeit not always applicable.
Undetectable information conflicts are those where a machine lacking
human intelligence cannot reliable detect that the two pieces of
information cannot both be true. For example, an automaton is
unlikely to be able to decide which of several notes or free-text
fields is valid, without basing this on other information in the
tuple, person or device element.
6.3. Resolving Information Conflicts
Once an information conflict is detected, a choice must be made
between the conflicting elements in order to resolve the conflict. A
method must be determined for choosing between the elements. Once an
element is chosen, the scope of the resolution must be determined.
That is, it must be decided whether one entire tuple should be
removed, or only the element.
There are a number of approaches for choosing between conflicting
values. Specific methods may be combined with external information,
such as time of day. A number of common methods are listed below:
Schulzrinne, et al. Expires September 6, 2006 [Page 11]
Internet-Draft Composition March 2006
Choose recent tuple: Choose the element from the most recent tuple
only or from tuples no more than a certain age. Simply choosing
the most recently published value is likely to cause flip-flopping
between dueling publishers.
Choose trustworthy tuple: Choose the element from the most
trustworthy tuple. Trustworthiness may be based on the source
identity, such as a user's cell phone. More likely, it is based
on the types of reporting listed in Section 3. For example, they
may be ranked in the order "reported current", "measured device
information", "measured by sensors", "reported scheduled", and
finally "derived". Note that "derived" here refers to a more
complex derivation, not to the basic rules mentioned earlier,
where the derived data is about as reliable as the original
information.
Omit contradictions: A conservative approach omits any information
where two source tuples contradict each other. [Only the
intersection of enumerated sets, with their associated notes, is
used.]
Value of another element: Other elements may indicate that one
version of the information should be trusted. For example, <user-
input> may indicate that one device that provides presence is
being used by the user, and another is not. As a special case of
this policy, tuples belonging to a certain sphere may be given
precedence. For example, after a certain hour, it is more likely
that the tuple with the <home> sphere is up-to-date.
When one value is chosen over another, the resulting presence
document may be affected on the tuple level or on the element level.
On the tuple level, the more trusted tuple is chosen and the other is
discarded. On the element level, both tuples are maintained, but
only the more trusted element is kept, while the other is discarded.
Either of these approaches may have advantages in certain situations.
It is suggested that tuple-level conflict resolution be used to avoid
inconsistencies in the composed document.
7. Tuple Merging
Merging combines several tuples into one. This may be peformed on
tuples that logically represent the same information. For example, a
presence document should only contain one report of <person>
information, and the multiple reports from different sources must be
merged. Service <tuple>s that have the same contact URI should also
be merged. (We leave aside for now the difficulty of deciding
whether two URIs that are not lexically identical are indeed
functionally the same) This may occur when the same service is being
provided by a variety of devices, or in the example of static
information in Section 5. Multiple service <tuple>s may also be
Schulzrinne, et al. Expires September 6, 2006 [Page 12]
Internet-Draft Composition March 2006
combined to create a new service. For example, a composer could take
a variety of services (e.g., cell phone, home phone, office phone, PC
IM client) available under different contact URIs and create a new
service tuple that "hides" all these services behind a single SIP
URI. In such a case, a decision must first be made about how to
merge multiple tuples, based on the "pivot" model in [7].
In any of the above cases, the RPID elements in the resulting tuple
must be based on the original tuples. Although the original values
should not conflict, following the previous step, there must be
either a selection from among the values or a union of all values.
We discuss appropriate techniques for each element type below.
7.1. Service tuples
When composing <service> tuples, the following rules apply to their
RPID elements:
class: A single value needs to be chosen.
device: If a service is offered by multiple devices, it makes sense
to enumerate all the device identifiers.
privacy: Since the caller cannot select the device that satisfies
specific privacy requirements, the appropriate choice is to
provide the most conservative indication of the privacy to be
expected, i.e., the least privacy indicated among all the tuples
for the contact URI. [TBD: Note, however, that there are
proposals [11] to allow remote parties to indicate privacy
requirements.
relationship: If two tuples with the same contact URI differ in their
relationship, the relationship element needs to be dropped.
status icon: It is a local choice whether to present all status
icons, as they may reflect specific capabilities, or choose one.
user input: In a combined <tuple>, it makes sense to reflect the most
recent user input.
7.2. Person tuples
activities: As noted earlier, activities reported by a variety of
sources can easily all be true, as they may report on different
facets of a person. For example, for a driver talking on a cell
phone, a car sensor may report "steering", while the phone can
report "on-the-phone", and the calendar can indicate
"appointment". One option may be to report all recent activities.
class: As discussed for <tuple> above.
mood: This is similar to <activities>.
Schulzrinne, et al. Expires September 6, 2006 [Page 13]
Internet-Draft Composition March 2006
place-is: Selecting the least favorable value for each media type
appears to be a safe default operation.
place-type: One option may be to choose specific values over more
general ones, where "stadium" would win over "public".
privacy: As discussed for <tuple> above.
sphere: This element is also largely single-valued, so that a
selection needs to be made. Certain sphere values may be
preferred over others.
status-icon: As discussed for <tuple> above.
user-input: As discussed for <tuple> above.
As other elements are added, they are likely to either fall into the
category of elements where collecting all (recent) values makes most
sense, such as activities and mood above, and where a choice among
sources needs to be made.
8. Default Policy
The default composition policy is designed to lose no information, at
the expense of presenting possibly contradictory information to
watchers.
This composition policy performs a union with replacement. Newly
published elements replace earlier elements with the same 'id'
attribute. We assume that each source chooses their own 'id' values.
Other than this, all elements are simply enumerated as is, sorted by
type (person, tuple, device). Elements within the <person>, <tuple>
and <device> elements are not modified at all, except possibly
annotated with a source description (and timestamp?). This policy
can also be seen as providing input to the following steps.
9. Composition Policy Format
We define an XML format for specifying a policy for composition. It
is expected that this format will be used by users themselves, and
that standard composition documents be created by network
administrators. The document is a sequence of composition steps,
each with its own options for customization. The steps are
"discard", "derive", "resolve-conflicts", and "merge".
9.1. Discard step
This step allows for discarding of tuples. Three types of discarding
may be specified: discard all service tuples with closed contacts,
discard all tuples whose timestamps are older than a certain amount
Schulzrinne, et al. Expires September 6, 2006 [Page 14]
Internet-Draft Composition March 2006
of time, and discard all device tuples not associated with a service.
9.2. Derive step
This step contains rules for deriving new information based on
existing information. Each rule contains an "inputs" and "results"
section.
The "inputs" section contains one or more inputs as conditions for
adding one or more pieces of information in the "results" section.
An input may be the existence or value of an attribute, or
information external to the presence document, such as time of day.
All inputs must be satisfied in order for the results section to be
evaluated. In order to define an attribute as an input, Xpath is
used. In RPID, attributes are specified by separate elements, such
as <meeting>, as opposed to text values. In such a case, Xpath may
be used to refer to the existence of the attribute without performing
any selection. For example, the existence of a person tuple showing
the user in a meeting would be represented by '/person/activities/
meeting'. When the <other> element is used, Xpath must do a
selection based on the attribute value, such as 'person/
place-type[other="baby's room"]/other'.
The "results" section contains one or more "add" statements. These
are formatted based on [13]. The location of the addition is any
person, service or device tuple that matches the requirements in the
"inputs" section.
9.3. Resolve Conflicts Step
In this step, conflicts are identified and resolved using one of a
number of policies. The <resolve-conflicts> element contains
possibly several <conflict> elements, each defining how conflict is
to be resolved. An "element" attribute may be included so that the
included policy applies only to that element. When this attribute is
omitted, or has a value of "default", it applies to all elements. We
currently assume that the "geopriv" element value will signal to the
compositor that the rule applies whenever it identifies a divergence
of location (possibly by using a local algorithm to convert between
civic and geodetic values). The <conflict> element also has a
"scope" attribute that takes a value of either "tuple" or "element."
With the value of "tuple", once a conflict is identified, the less
trusted tuple is removed entirely. With the value of "element", both
tuples remain, but only the element from the more trusted tuple is
kept. As mentioned above, element-level conflict resolution may
introduce inconsistent data.
Options for resolution are "union", "source-precedence", or "other-
Schulzrinne, et al. Expires September 6, 2006 [Page 15]
Internet-Draft Composition March 2006
attribute". Choosing "union" causes even conflicting information to
be included, and precludes the inclusion of any other policy.
Several policies may be listed, and conflict resolution is attempted
with each in the order that they appear, until one succeeds.
The <source-precedence> element lists a number of source types. This
list may contain any of the following tokens at most once: "reported
current", "reported scheduled", "measured device information",
"measured by sensors", "derived". If each of the conflicting tuples
is from one of the sources listed, the one with a higher value is
chosen. If only one of the tuples is from a source with a listed
value, that one is chosen. If neither of them are, the conflict is
not resolved.
The <other-attribute> element specifies that resolution be done based
on another element besides the one in conflict. An attribute is
included to specify the attribute with Xpath. A list of elements
gives the ordered preference of various values of the attribute.
9.4. Merge Step
This final step merges multiple tuples to present a final view of the
user's presence before continuing to later steps such as privacy
filtering. Merging is done separately on <person>, <tuple> and
<device> tuples. Merging in this format involves two steps: pivoting
and choosing values for attributes. We do not include an additional
step mentioned in [7], which is choosing a single URI to represent
the merged service.
Pivoting is the process of merging all tuples into a smaller set
based on a common attribute, where each new tuple represents all
tuples with a certain value of the attribute. Services and devices
may be grouped in this way. However, person information does not
lend itself to multiple tuples, so all tuples are merged into a
single one (note that this is a special case of pivoting).
When multiple tuples are merged, they may have different values for
the same attribute. This is because different values are often not
contradictory. An example is the <place-type> attribute, where two
sources may give the values "outdoors" and "construction", and the
value "construction" is simply more specific. A <choose-value>
element is defined, which contains a list of one or more policies to
be applied, such as <list-all>, <more-specific>, or <less-specific>.
Multiple <choose-value>s may be defined, with the "element" attribute
distinguishing the element for which the list applies, so that
different policies may be applied to different elements. If the
attribute is not included, or has a value of "default", the policy
applies to all elements. When no policy exists to distinguish
Schulzrinne, et al. Expires September 6, 2006 [Page 16]
Internet-Draft Composition March 2006
between two values, the default is to list all values.
10. XML Example
[We plan to include an XML schema once the format is more or less
agreed upon]
<discard>
<old time-since-expiration="00:05:00.000" />
<tuples-with-closed-contacts />
<devices-without-services>
</discard>
<derive>
<derivation>
<inputs>
<input element='person/activity/on-the-phone' />
</inputs>
<results>
<result element='person/activity/busy' />
</results>
</derivation>
<derivation>
<inputs>
<input element='/tuple[device-id="mac:8asd7d7d70"]/device-id' />
</inputs>
<results>
<add sel=/tuple/status/"><gp:geopriv><gp:location-info>
<gml:location><gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates></gml:Point>
</gml:location><gp:location-info></gp:geopriv></add>
</results>
</derivation>
</derive>
<resolve-conflicts>
<conflict element="geopriv" scope="tuple">
<other-attribute attribute='/person/user-input'>
<value>active</value>
<value>idle</value>
</other-attribute>
</conflict>
<conflict element="default" scope="tuple">
<source-precedence>
<source>reported current</source>
<source>reported scheduled</source>
</source-precedence>
<other-attribute attribute='/person/user-input'>
Schulzrinne, et al. Expires September 6, 2006 [Page 17]
Internet-Draft Composition March 2006
<value>active</value>
<value>idle</value>
</other-attribute>
<other-attribute attribute='/person/scope'>
<home>
<work>
</other-attribute>
</conflict-element>
</resolve-conflicts>
<merge>
<persons>
<choose-value element="default">
<more-specific>
</choose-value>
</persons>
<services>
<pivot attribute='/tuple/class' />
<choose-value element="default">
<more-specific>
</choose-value>
</services>
</merge>
11. Security Considerations
Composition itself does not create new data types, although it might
create new elements by inference. Thus, the security considerations
are the same as those for the constituent presence information
elements.
12. IANA Considerations
This document does not request any IANA actions.
13. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
Schulzrinne, et al. Expires September 6, 2006 [Page 18]
Internet-Draft Composition March 2006
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[4] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-10 (work in progress), December 2005.
[5] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals",
draft-ietf-simple-future-05 (work in progress), December 2005.
[6] Rosenberg, J., "A Data Model for Presence",
draft-ietf-simple-presence-data-model-07 (work in progress),
January 2006.
[7] Rosenberg, J., "A Processing Model for Presence",
draft-rosenberg-simple-presence-processing-model-01 (work in
progress), August 2005.
[8] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-07 (work in
progress), February 2006.
[9] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004.
[10] Lonnfors, M., "Session Initiation Protocol (SIP) extension for
Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-06 (work in progress),
October 2005.
[11] Shacham, R., "Use of the SIP Preconditions Framework for Media
Privacy", draft-shacham-sip-media-privacy-01 (work in
progress), November 2005.
[12] Isomaki, M., "An Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usage for Manipulating Presence
Document Contents",
draft-ietf-simple-xcap-pidf-manipulation-usage-02 (work in
progress), October 2004.
[13] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-01 (work in
progress), January 2006.
Schulzrinne, et al. Expires September 6, 2006 [Page 19]
Internet-Draft Composition March 2006
Appendix A. Acknowledgments
This document is based on discussions within the IETF SIMPLE working
group. Paul Kyzivat provided helpful input.
Schulzrinne, et al. Expires September 6, 2006 [Page 20]
Internet-Draft Composition March 2006
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu
Ron Shacham
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Email: rs2194@cs.columbia.edu
Wolfgang Kellerer
DoCoMo Eurolabs
Landsberger Str. 312
Munich 80687
Germany
Email: kellerer@docomolab-euro.com
Srisakul Thakolsri
DoCoMo Eurolabs
Landsberger Str. 312
Munich 80687
Germany
Email: thakolsri@docomolab-euro.com
Schulzrinne, et al. Expires September 6, 2006 [Page 21]
Internet-Draft Composition March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne, et al. Expires September 6, 2006 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 19:28:32 |