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

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

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

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

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

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

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

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

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

Example Static Document Published Content Final + = <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> <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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open Issues for Derivation Should “static derivation” be done through derivation rules, a static XML document or both? 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? 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” IETF 66 SIMPLE WG Meeting