composing presence information henning schulzrinne ron shacham wolfgang kellerer srisakul thakolsri...
TRANSCRIPT
Composing Presence Information
Henning Schulzrinne
Ron Shacham
Wolfgang Kellerer
Srisakul Thakolsri
(ID-schulzrinne-simple-composition-02)
IETF 66 SIMPLE WG MeetingJuly 11, 2006
IETF 66 SIMPLE WG Meeting
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
<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>
Static Document<device> <deviceID>AAAAAB</deviceID></device>
Published Content<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>
Final
+ =
IETF 66 SIMPLE WG Meeting
Example
<tuple> <status> <basic>closed</basic> </status> <contact priority="0.8">
sip:[email protected]; 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>
Static Document<tuple> <status> <basic>open</basic> </status> <contact priority="0.8"> sip:[email protected]; opaque="kj444444Hw";gruu </contact></tuple>
Published Content<tuple> <status> <basic>open</basic> </status> <contact priority="0.8">
sip:[email protected]; 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>
Final
+ =
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
<derive>
<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
<resolve-conflicts> <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> <other-attribute attribute='//person/user-input'> <value>active</value> <value>idle</value> </other-attribute> </conflict>
</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?– 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”