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

2. IETF 66 SIMPLE WG Meeting 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

3. IETF 66 SIMPLE WG Meeting 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

4. IETF 66 SIMPLE WG Meeting 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

5. IETF 66 SIMPLE WG Meeting 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

6. IETF 66 SIMPLE WG Meeting 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’

7. IETF 66 SIMPLE WG Meeting 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

8. IETF 66 SIMPLE WG Meeting 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

9. IETF 66 SIMPLE WG Meeting Example AAAAAB US Broadway 123 Static Document AAAAAB Published Content AAAAAB US Broadway 123 Final +=

10. IETF 66 SIMPLE WG Meeting Example closed sip:bob@example.com; opaque="kj444444Hw";gruu AAAAAB AAAAAB US Broadway 123 Static Document open sip:bob@example.com; opaque="kj444444Hw";gruu Published Content open sip:bob@example.com; opaque=“kj444444Hw”;gruu AAAAAB AAAAAB US Broadway 123 Final +=

11. IETF 66 SIMPLE WG Meeting 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

12. IETF 66 SIMPLE WG Meeting 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’

13. IETF 66 SIMPLE WG Meeting 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’

14. IETF 66 SIMPLE WG Meeting 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

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

16. IETF 66 SIMPLE WG Meeting Discard Step Service tuples with closed contacts Tuples older than some threshold Devices not associated with a service Example:

17. IETF 66 SIMPLE WG Meeting 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 ) XML patch format is used, with ‘sel’ attributed acting as predicate – Multiple Xpath predicates may be used for multiple conditions

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

19. IETF 66 SIMPLE WG Meeting 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

20. IETF 66 SIMPLE WG Meeting Resolve Conflicts Example active idle reported current reported scheduled active idle

21. IETF 66 SIMPLE WG Meeting 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)

22. IETF 66 SIMPLE WG Meeting 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

23. IETF 66 SIMPLE WG Meeting 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

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

25. IETF 66 SIMPLE WG Meeting 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?

26. IETF 66 SIMPLE WG Meeting 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”