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

2. Presence composition: where is OMA right now? OMA Presence composition policy: Presence Server (PS) PS groups s with same,, and composes two s in one if they have non-conflicting elements Otherwise PS keeps s separate Service identification »Uniquely identifies the OMA-specific service »Example: org.openmobilealliance:PoC-session service URI: PIDF including AoR PS composes two instances in one if they have non- conflicting elements Otherwise PS keeps instances separate PS groups s with same 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 instances By default: choose the one with the latest

3. 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. PoC Server vs. PoC 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

4. 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     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    open/closed Overriding willingness takes precedence over the application-specific willingness maps to     open/closed Communication address:  Activity: [RPID] Note: , 

5. Presence attributes in OMA (2/2) Location:  [RPID] Geographical Location: -> -> and -> -> [PIDFLO] Timezone: [RPID] Mood: [RPID] Icon:  [RPID] Timestamp: Class: Session-participation user is involved in at least one session of a specific service maps to     open/closed Network Availability:   OMA PIDF extensions:,,,,

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

7. Device-id OMA chosen identifier for in and in : 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

8. Example for OMA extensions in open open open org.openmobilealliance:PoC-Session 1.0 OMA PoC-Session omai:be874b7a3a3fce7d0e91649a97762e64 sip:my_name@example.com 2005-02-22T20:07:07Z

9. Authorization issues : XCAP URI of a “resource-lists” document pointing to an external URI List : matches all identities that are not referenced in any rule allows for specifying a default policy Extensions for : (this relates to an IETF defined element) (as child of ) 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?