Composing Presence Information

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: servicetuples 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 <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> Static Document Published Content Final <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 <tuple> <status> <basic>closed</basic> </status> <contact priority="0.8"> sip:bob@example.com; 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> Static Document Published Content Final <tuple> <status> <basic>open</basic> </status> <contact priority="0.8"> sip:bob@example.com; opaque="kj444444Hw";gruu </contact> </tuple> <tuple> <status> <basic>open</basic> </status> <contact priority="0.8"> sip:bob@example.com; 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 <derive> <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 <resolve-conflicts> <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> <other-attribute attribute='//person/user-input'> <value>active</value> <value>idle</value> </other-attribute> </conflict> </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? • 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