Presence Composition draft-schulzrinne-simple-composition-00 Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu August 2005 IETF 63 - SIMPLE

Roles of Composition composition = combines multiple presence or event sources into one view remove information: stale, contradictory, redundant create new information (e.g., new composite services) August 2005 IETF 63 - SIMPLE

(Simplifying) assumptions Focus on PIDF/RPID, but probably applicable to other event sources Depends on presentity, but not on watcher i.e., provides maximum information set for later stages May be prefaced by general transformation step independent of presentity Reactive: triggered by new data (PUBLISH) avoid triggering by rule changes “Watcher A’s permissions increased at 9 pm” August 2005 IETF 63 - SIMPLE

Operations Tuple-level selection or union Element-level: could also trim some tuples Element-level: multiple instances of the same element type <activities><sleeping/></activities> {from S1} <activities><steering/></activities> {from S2} new element that combines values <activities><sleeping/><steering/></activities> August 2005 IETF 63 - SIMPLE

Sources of presence data Reported current added manually a brief time ago assumed correct when entered, but decays Reported scheduled from a calendar Measured device information communication status Measured by sensors location, type of location, activity, … sensors = GPS, acceleration sensors, PIRs, ... Derived from other presence data August 2005 IETF 63 - SIMPLE

Sources of information conflict Location divergence Alice’s home PC reporting while Alice is at work Update diligence most people don’t record all obligations in their calendar Sensor failure no new data = sensor failure OR nothing new? August 2005 IETF 63 - SIMPLE

Detecting information conflicts Single elements or across elements Obvious, probable, or undetectable Examples Single element = two different locations for same person but differing activities or location types do not automatically conflict obvious: diverging privacy values probable: “sleeping” + “steering” August 2005 IETF 63 - SIMPLE

Composition steps source discard resolve closed + ambiguities old union with replacement combine identical contacts August 2005 IETF 63 - SIMPLE

Ambiguity resolution choose recent tuple choose trustworthy tuple most recent or ignore old (> T) choose trustworthy tuple based on source "reported current", "measured device information", "measured by sensors", "reported scheduled", and finally "derived" omit contradictions only items with no disagreements choose by sphere value precedence “meeting” > “tuple” location-based August 2005 IETF 63 - SIMPLE

<person> merging Could make only safe merging decisions don’t present uncertain information <activities> are often complementary e.g., <place-is>  pick least-favorable August 2005 IETF 63 - SIMPLE

Service merging Two separate problems: Aggregation of tuples with same URI  capability merging max (best case) – selectable by CallerPref min (at least get, regardless of proxy actions) Create new AOR that represents multiple services requires mechanism to create these August 2005 IETF 63 - SIMPLE

Device merging Use cases? Copy+merge capabilities into service? August 2005 IETF 63 - SIMPLE

Tuple merging Keep multiple (cleaned-up) <person>s (and maybe devices) maintains notion of separate sources Combine into one <person> simpler to process and render August 2005 IETF 63 - SIMPLE

Open (meta) issues Source labeling – which draft venue? Simple composition policy language might be able to do simple selection operations (“discard old > 3600 s”) August 2005 IETF 63 - SIMPLE