1. Composing Presence Information
(ID-schulzrinne-simple-composition-02)
Henning Schulzrinne
Ron Shacham
Wolfgang Kellerer
Srisakul Thakolsri
IETF 66 SIMPLE WG Meeting
July 11, 2006

2. Motivation for Composition
Information about presentity comes from different sources and is updated frequently
In order for presentation to be more useful to the watcher, we wish to:
Remove stale information
Remove contradictory information
Remove redundant information
Generate new, inferred presence information
Represent information in a useful way
IETF 66 SIMPLE WG Meeting

3. Steps of Composition Discarding stale and redundant information
Derivation of new presence information
Conflict Resolution to remove contradictory information
Tuple Merging to represent presence in a useful way
IETF 66 SIMPLE WG Meeting

4. Discarding
Closed contacts: service tuples with a basic status ‘closed’
Old tuples: person, service or device tuples with a timestamp older than a given threshold (but not yet expired)
Unreferenced tuples: device tuples not referenced by any service tuple
IETF 66 SIMPLE WG Meeting

5. Deriving Presence Information
Provides information to compositor that facilitates conflict resolution
Two different versions of person information are sent by two different devices with different locations (based on geopriv extensions), and user cannot be using both
Provides additional information to watcher
IETF 66 SIMPLE WG Meeting

6. Provide Additional Information to Watcher
Device may not support certain extensions and so cannot publish that information
Users may not always express presence information manually, and there are many associations that can be automatically made
Usage examples:
‘On-the-phone’ => ‘busy’
Place-type=‘car’ => activity=‘driving’
‘idle’ during certain hours => activity=‘sleeping’
IETF 66 SIMPLE WG Meeting

7. Derivation of Presence Information
{Predicate} => {New XML Content}
New content may be dynamic or static
Dynamic content is added only under specific circumstances, defined by the predicate
Other elements in the presence document
Additional information such as the time of day
Static content is always added to a specific device or service tuple
IETF 66 SIMPLE WG Meeting

8. Static presence information
Example
My home PC is in a certain location—include location even though it isn’t published by the PC
A rule can be defined for this:
deviceID =.. =>content
contact=sip:…=> content
Alternatively, use a static present document
The concept is defined in XCAP Presence Manipulation draft
It is another input to the compositor, like presence information received through PUBLISH or NOTIFY
Information representing identical service or device is joined during merging stage
IETF 66 SIMPLE WG Meeting

9. Example Static Document Published Content Final + =
<device>
<deviceID>AAAAAB</deviceID>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
</cl:civilAddress>
</gp:location-info>
</gp:geopriv>
</device>
<device>
<deviceID>AAAAAB</deviceID>
</device>
<device>
<deviceID>AAAAAB</deviceID>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
</cl:civilAddress>
</gp:location-info>
</gp:geopriv>
</device> + =
IETF 66 SIMPLE WG Meeting

10. Example Static Document Published Content Final + =
<tuple>
<status>
<basic>closed</basic>
</status>
<contact priority="0.8">
opaque="kj444444Hw";gruu
</contact>
<dm:deviceID>
AAAAAB
</dm:deviceID>
</tuple>
<device>
<deviceID>AAAAAB</deviceID>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
</cl:civilAddress>
</gp:location-info>
</gp:geopriv>
</device>
<tuple>
<status>
<basic>open</basic>
</status>
<contact priority="0.8">
opaque="kj444444Hw";gruu
</contact>
</tuple>
<tuple>
<status>
<basic>open</basic>
</status>
<contact priority="0.8">
opaque=“kj444444Hw”;gruu
</contact>
<dm:deviceID>
AAAAAB
</dm:deviceID>
</tuple>
<device>
<deviceID>AAAAAB</deviceID>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
</cl:civilAddress>
</gp:location-info>
</gp:geopriv>
</device> + =
IETF 66 SIMPLE WG Meeting

11. Conflict Resolution
Allows the compositor to remove inaccurate information
Must first detect information conflict, then choose how to resolve it
Usage examples:
Calendar information reports user in a meeting somewhere, but the meeting has been cancelled
User has reported different levels of privacy
IETF 66 SIMPLE WG Meeting

12. Detecting Information Conflict
Some information conflict can be easily detected
‘place-is’
‘privacy’
Location information
For other information, conflict is less clear
‘activity’ could be ‘on-the-phone,’ ‘away’ and ‘appointment’
‘place-type’ could be ‘outside’ and ‘stadium’
IETF 66 SIMPLE WG Meeting

13. Resolving Information Conflict
Keep “better” tuple and discard the other
There are many possible methods of conflict resolution
Recently published tuple
More trustworthy tuple
Specific source’s identity
Type of source: ‘reported current’, ‘measured device information’, ‘measured by sensors’, ‘reported scheduled’
Value of another element in tuple, such as ‘idle’ or ‘sphere’
In some cases, the conflict is better NOT resolved
Keep both tuples intact and let the watcher choose
Keep all values and list them all during tuple merging
Possibly the best choice for ‘mood’ and ‘activities’
IETF 66 SIMPLE WG Meeting

14. Tuple Merging Join multiple tuples into one
Tuples that logically refer to the same entity
All person tuples
All service tuples that refer to the same contact URI (eg. the same GRUU)
Since conflict resolution has already been done, this step is trivial for these two categories, and no user specification is needed
IETF 66 SIMPLE WG Meeting

15. Composition Policy Format
Discard step
Derive step
Resolve Conflicts step
Merge step
IETF 66 SIMPLE WG Meeting

16. Discard Step Service tuples with closed contacts
Tuples older than some threshold
Devices not associated with a service
Example:
<discard>
<old age="00:30:00.000" />
<tuples-with-closed-contacts />
<devices-without-services>
</discard>
IETF 66 SIMPLE WG Meeting

17. Derive Step Made up of a series of rules
Each rule has a predicate and added XML content
A predicate is one or more conditions that must all be satisfied in order to produce the new content
Existence or value of an attribute
Time of day (based on <timestamp>)
XML patch format is used, with ‘sel’ attributed acting as predicate
Multiple Xpath predicates may be used for multiple conditions
IETF 66 SIMPLE WG Meeting

18. Derive Step Example <add sel='//person[place-type/car] \
[fn:hours-from-dateTime(timestamp) > 9 and \ fn:hours-from-dateTime(timestamp) < 12]'>
<activities>
<driving>
</activities>
</add>
</derive>
IETF 66 SIMPLE WG Meeting

19. Resolve Conflicts Step
Conflict detection is based on local policy
User may decide how to resolve a conflict
A separate policy may be defined for any given element, or for all elements not covered by another policy
When several resolution policies are defined for an element, they are tried in order until one succeeds
The default policy is to keep both conflicting tuples
IETF 66 SIMPLE WG Meeting

20. Resolve Conflicts Example
<conflict element=‘//person/gp:geopriv/gp:location-info/cl:civicAddress/cl:HNO’>
<other-attribute attribute='//person/user-input'>
<value>active</value>
<value>idle</value>
</other-attribute>
</conflict>
<conflict element=“all">
<source-precedence>
<source>reported current</source>
<source>reported scheduled</source>
</source-precedence>
</resolve-conflicts>
IETF 66 SIMPLE WG Meeting

21. Merge Step We currently only specify the merging of person tuples
Since conflict resolution has been done, all persons should be merged, and no format is needed for this step
Merging of tuples for the same service or device is useful for use with static XML document (derivation)
IETF 66 SIMPLE WG Meeting

22. Big Questions User-specified rules or guidelines?
Per-presentity or per-watcher?
For rule language, per-presentity seems sufficient
conflict resolution does not seem to depend on watcher
establish “truth”, then tailor it to watcher
More complicated tailoring probably requires a programming language
IETF 66 SIMPLE WG Meeting

23. Big Questions - Scope Use cases? Non-presence sources
Existing systems of little use - don’t have multiple sources of presence
Non-presence sources
Yes, should be integrated --> transformation rules
IETF 66 SIMPLE WG Meeting

24. Open Issues for Derivation
Should “static derivation” be done through derivation rules, a static XML document or both?
IETF 66 SIMPLE WG Meeting

25. Open Issues for Conflict Resolution
How should location divergence be expressed?
A special generic attribute is more appropriate than referencing a specific civil address element
Should degree of location divergence be supported?
IETF 66 SIMPLE WG Meeting

26. Open Issues for Tuple Merging
Is it useful to also merge multiple services associated with same AOR? (eg. when each has its own GRUU)
Merging of these requires choosing from element values
Are conflict resolution heuristics, such as latest publish, appropriate?
There are other heuristics based on the values themselves, such as “give the most conservative privacy value”
IETF 66 SIMPLE WG Meeting