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:bob@example.com; 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:bob@example.com; opaque="kj444444Hw";gruu </contact></tuple>

Published Content<tuple> <status> <basic>open</basic> </status> <contact priority="0.8">

sip:bob@example.com; 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”