SIMPLE Drafts Jonathan Rosenberg dynamicsoft

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

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

Example Message NOTIFY 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: …

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

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

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

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]

Data Requirements

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

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

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

Authorization Model PA List1 List2 Logic Script Data Manipulations

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

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

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

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?