OMA Presence 1 0 Presence attribute composition issues

OMA Presence 1. 0 Presence attribute, composition issues Krisztián Kiss krisztian. kiss@nokia. com

• Presence composition: where is OMA right now? OMA Presence composition policy: Presence Server (PS) • PS groups <tuple>s with same <contact> , <service-description>, <device-id> and composes two <tuple>s in one <tuple> if they have non-conflicting elements • Otherwise PS keeps <tuple>s separate • Service identification <service-description> » Uniquely identifies the OMA-specific service » Example: org. openmobilealliance: Po. C-session service URI: PIDF <contact> including Ao. R PS composes two <person> instances in one <person> if they have nonconflicting elements • Otherwise PS keeps <person> instances separate • PS groups <device>s with same <device. ID> and chooses elements from the most recent publication for conflicting elements • OMA Presence composition policy: Watcher • For every presence attribute defined by OMA, there is recommendation on how to resolve ambiguities • Decide among the different tuples representing the same service • Decide among the different <person> instances • By default: choose the one with the latest <timestamp> •

Presence composition: what is the next step? • PS should implement “smart” composition and do not leave ambiguities for the watcher • For conflicting elements, “overriding with the latest published” solution is not necessary the best • PS could determine the actions based on the “weight” of the publisher (e. g. Po. C Server vs. Po. C Client, IM server vs. IM client) Þ Compositor to perform actions based on publishers’ privileges and needs • Pros • Makes watcher simpler, results in a consistent interpretation • Cons • Less extensible • Compositor needs knowledge of semantics and sources

Presence attributes in OMA (1/2) • Person/Device/Tuple • Application-specific willingness • whether the user desires to receive incoming communication requests for the particular service instance on a particular device • maps to <tuple> <status> <willingness> <basic> open/closed • Application-specific availability • whether it is possible to receive incoming communication requests for the particular service instance on a particular device • maps to <tuple> <status> <basic> open/closed • Overriding willingness • takes precedence over the application-specific willingness • maps to <person> <status> <overriding-willingness> <basic> open/closed • Communication address: <tuple> <contact> • Activity: <activities> [RPID] • Note: <person> <note>, <tuple> <note>

Presence attributes in OMA (2/2) • Location: <person> <place-type> [RPID] • Geographical Location: <status> -> <geopriv> -> <location-info> and <status> -> <geopriv> -> <usage-rules> [PIDFLO] • Timezone: <time-offset> [RPID] • Mood: <mood> [RPID] • Icon: <person> <status-icon> [RPID] • Timestamp: <timestamp> • Class: <class> • Session-participation • user is involved in at least one session of a specific service • maps to <tuple> <status> <session-participation> <basic> open/closed • Network Availability: <device> <status> <network-availability> • OMA PIDF extensions: <service-description>, <willingness>, <overridingwillingness>, <network-availability>, <session-participation>

PIDF dependencies • OMA Presence 1. 0 has explicit list of presence attributes • All XML elements from PIDF, Presence Data Model are required • Partially, the XML elements from RPID are required • But how about other elements from RPID? • And, how about PRESCAPS, CIPID, FUTURE, etc? • • In the first release, there is no explicit requirement to have these extensions But, these and other extensions may be supported by an implementation (no direct recommendation to do so) if the extensions can be ignored without changing the meaning of the attributes that are supported

Device-id • OMA chosen identifier for <device. ID> in <device> and <device-id> in <tuple>: • Pseudo-random hexadecimal number, 128 -bits long, 32 hexadecimal digits • Proposed format: urn: omai: xxxx. . . • utilizes existing URN framework • needs 'omai' NID to be registered with IANA using the template and procedures in RFC 3406

Example for OMA extensions in <tuple> • <tuple id="a 1231"> <status> <basic>open</basic> <willingness><basic>open</basic></willingness> <session-participation> <basic>open</basic> </session-participation> </status> <service-description> <service-id>org. openmobilealliance: Po. C-Session</service-id> <version>1. 0</version> <description>OMA Po. C-Session</description> </service-description> <device-id>omai: be 874 b 7 a 3 a 3 fce 7 d 0 e 91649 a 97762 e 64</device-id> <contact>sip: my_name@example. com</contact> <timestamp>2005 -02 -22 T 20: 07 Z</timestamp> </tuple>

Authorization issues • <external-list>: XCAP URI of a “resource-lists” document pointing to an external URI List • <other-identity>: • matches all identities that are not referenced in any rule • allows for specifying a default policy • Extensions for <transformations>: • <provide-willingness> • <provide-network-availability> • <provide-session-participation> • <provide-geopriv> (this relates to an IETF defined element) • <service-id> (as child of <provide-services>) • In the next release, there may be requirements in OMA to adopt prescaps, cipid, future, XCAP hard-state publication -> will IETF define authorization rules for these I-Ds?