1. Presence Composition draft-schulzrinne-simple-composition-00
Henning Schulzrinne
Dept. of Computer Science
Columbia University
August 2005
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)
August 2005
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”
August 2005
IETF 63 - SIMPLE

4. 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

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
August 2005
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?
August 2005
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”
August 2005
IETF 63 - SIMPLE

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

9. 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

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
August 2005
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
August 2005
IETF 63 - SIMPLE

12. Device merging Use cases? Copy+merge capabilities into service?
August 2005
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
August 2005
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”)
August 2005
IETF 63 - SIMPLE