Presence Composition draft-schulzrinne-simple-composition-00

1. Presence Compositiondraft-schulzrinne-simple-composition-00 Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu IETF 63 - SIMPLE

2. 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) IETF 63 - SIMPLE

3. (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” IETF 63 - SIMPLE

4. Operations • Tuple-level selection or union • 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> IETF 63 - SIMPLE

5. 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 IETF 63 - SIMPLE

6. 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? IETF 63 - SIMPLE

7. 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” IETF 63 - SIMPLE

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

9. Ambiguity resolution • choose recent 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 IETF 63 - SIMPLE

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

11. 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 IETF 63 - SIMPLE

12. Device merging • Use cases? • Copy+merge capabilities into service? IETF 63 - SIMPLE

13. 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 IETF 63 - SIMPLE

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