1. SIMPLE Drafts Jonathan Rosenberg dynamicsoft

2. Presence List Changes Terminology change Presence List Information Data Format –Provides version, full/partial flag Lists can contain lists –List server subscribes to list package for each entry, since it doesn’t know whether it’s a list

3. Issue #1: Template or not? Template Package –“Collection” –Represents a list of elements for a package –Might be useful for mwi – multiple inboxes Would a new body type be needed for each templated package? –Seems wasteful Proposal –Make it a template class –Mandate multipart/mixed + base class mandatory type –Define headers/body type that JUST conveys version/partial information Don’t munge original document –Specify requirements on packages that can be templated Must provide URI for element about which document contains state

4. Example Message NOTIFY sip:subscriber@example.com SIP/2.0 Content-Type: multipart/mixed;boundary=--- Content-Length: … --- Content-Type: application/versioninfo Content-Length: … Version: 1 State: partial --- Content-Type: application/cpim-pidf+xml Content-Length: …

5. Issue #2: Too Many Choices Current Draft allows –PIDF Can just pass on content received from downstream PA Versioning issues –PLIDF Versioning/state flags there Requires munging XML – breaks signatures –Multipart Mixed Multiple documents unmodified Versioning issues Partial/full flag missing Collection Template Proposal Solves this –Only mixed –Define a new type (listinfo) that conveys state and version

6. Issue #3: State of subscriptions PLS passes state of subscribed entities to subscriber What about state of those subscriptions? –Would like to know that a buddy on the list has rejected the subscription –Normally contained in Subscription-State header –Can’t use that Proposal –Place information is listinfo format! –Listinfo can contain an entry for each element in the list –For each entry, it indicates state of subscription to that entry –Support partial updates for that list

7. Issue #4: Sharing of versions Current draft “shares” version numbers across PIDF/PLIDF –Seems wrong This is fixed with listinfo proposal

8. Issue #5: Which package does PLS Use? How does PLS know whether to use presence or presence.collection for each list entry? Solutions –[1] Try presence.collection, fallback to presence –[2] List URIs have syntactic sugar to indicate that they are lists –[3] User has to know that they are lists –[4] Server OPTIONS the URI once, then uses appropriate package Assumes it can’t change roles Proposal –Not [2]

9. Data Requirements

10. Problem Statement Presence and IM Systems make use of several “data elements” –Buddy list –Authorization Datum Allow list Deny list Logic Need to manipulate these, interact with them

11. Buddy List Model SUBSCRIBE +--------+ --------------->| | Read | PA |<--+ //----\\ <---------------| | | || || NOTIFY +--------+ +--- \\----//| | | | Storage| | | +--------+ | | | Server |------> | | | | Write \ / | | \------/ +--------+ ^ | | | | | BL | | Manipulations | | | V +--------+ | Client | | | +--------+

12. BL Requirements Write Manipulations –Create, add user, delete user, modify user, clear all, delete list Read Manipulations –Read list Caching –Client can store copy –Modify while offline –Resync with master copy in network Security –Authentication, privacy, integrity

13. Authorization Model PA List1 List2 Logic Script Data Manipulations

14. Auth Requirements Write Manipulations –Create, add user, delete user, modify user, clear all, delete list –Create/modify/delete logic Read Manipulations –Read list/logic Caching –Client can store copy –Modify while offline –Resync with master copy in network Security –Authentication, privacy, integrity

15. General Problem Here Application has a number of data elements –Each has a name –Each has a type List Blob Client needs to manipulate data elements –Type specific write/read operations –Caching –Security, etc. Client binds app data elements to instances of the appropriate types

16. Model Example Application +-----------------------------------+ | | | baz | | +-+ | | | | | | foo bar | | | | +--+ +----+ | | | | | | | | | | | | +----+ /+------+ | +---+ +---------+ / | | +---------/---------------V-----------------------+ | / +--+ +-+--+ | +-+ | | V |B | | E | | | | | | +--+ +--+ +----+ | | | | | |A | | |G| | | +--+ | | | | | +--+ | +-+ | | |C | V | | +--+ +-+ | | | | | | object +----+ | | | | pool | D | |F| | | +----+ | | | | +-+ | | | +-------------------------------------------------+ Data Storage

17. Open Issues Do enough RPC type operations fit under data manipulation to merit this approach? –Not clear yet in the case of conference control –Answer is yes if its represented through policy objects Should we go for the general solution or specific one for BL/auth? Alignment with SIP conferencing work is essential Adopt as a work item?