1 / 14

Presence Composition draft-schulzrinne-simple-composition-00

Presence Composition draft-schulzrinne-simple-composition-00. Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu. Roles of Composition. composition = combines multiple presence or event sources into one view

vito
Download Presentation

Presence Composition draft-schulzrinne-simple-composition-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related