Jonathan Rosenberg dynamicsoft Data Manipulation Jonathan Rosenberg dynamicsoft

Where are we Problem Statement Big idea: Use a generic mechanism Manipulate buddy lists (create, list, add, delete) Manipulate authorization policy (black/white lists, per-attribute permissions, etc.) Captured in draft-ietf-simple-data-req Big idea: These are just examples of application data manipulation Use a generic mechanism ACAP is close

What is ACAP? Application Configuration Access Protocol, RFC2244 (Issued November 1997) Target application: Server-based storage and client access to web browser address books and bookmarks Goal: Generic mechanisms for application-independent access to per-user application configuration data from multiple clients

ACAP Quick Summary Protocol operates much like IMAP in its syntax and message flow Client/Server Text-based SASL for security Based on the ACAP Data Model Hierarchical tree of name/value pairs Server doesn’t care about the meanings of the names or values Each usage defines a convention – ACAP Dataset Class – on what the names and values mean Only the clients care about this (usually)

ACAP Key Concepts Access Controls are Built In Inheritance Each attribute has an acl which defines what users can do with it Inheritance One part of the tree can inherit from another But can make local modifications that are not reflected in the parent Usage: department wide buddy lists ACAP URL: points to a tree locally or on another server Synchronization Multiple clients can access the data Versioning for collision detection, notifications to indicate if it changes under you

ACAP Primitives Rights Management Quotas Searching Boolean expressions on attributes Can limit number of responses, response pagination, sorting of response, list specific attributes to return STORE command Create, modify, delete entries Can be conditioned on a version number Can set multiple attributes at once Rights Management Can set and delete ACLS Can query for permissions visible to themselves Quotas Maximum amount of data per user

The Presence List Each entry in the tree is either another list or a presentity A presentity has attributes for The URI to subscribe to A display name An ACAP URL for an address book entry A list has attributes for A display name A URI to use to subscribe to it Inheritance is possible Department or company wide lists

Authorization Policy Each entry in the tree is a watcher or a list of watchers Each attribute specifies a permission Can they subscribe What attributes will they see “Inversion” of a black/white list Requires a well specified set of processing logic as part of dataset class Benefits of this model Allows for inheritance to work Avoids the needs for scripts (described previously in requirements document) Enables capabilities discovery Allows for operator defined permissions and user defined permissions I.e., “friend”

Permissions Notification Attributes Status attributes Presence-auth-list.onEvent.any .ontransition: from state to a state Etc. Content Attributes Presence-auth-list.content.tuples: list of tuples that can be seen Presence-auth-list.content.status-type: status types that can be seen Transformational Attributes “lying” Status attributes presence-auth-list.Accept.Any – anyone can subscribe presence-auth-list.accept.TOD – value is an iCal object for tod subscriptions Presence-auth-list.Accept.ReqTuples – authorize requested tuples Etc.

Permission Groups User defined sets of permissions For example, “friend” Accept any subscription Let them see non-work phone and IM Each group is defined by a set of primitive permissions

Capabilities List of permissions supported by the provider Both primitive and vendor-defined Includes textual description of the permission Allows to “Grey Out” UI components not available for this provider

Open Issues ACAP Dataset Model works well for us, but ACAP itself has some problems Based on a long-lived persistent TCP connection Doesn’t work well with intermittent connectivity SASL security not a good match for the rest of SIP No support for intermediaries Syntax not consistent with SIP

Proposal Specify SEACAP – SOAP Encoded ACAP Encompasses the query/response aspects of ACAP, omits the notifications Specify a SIP event package for data changes Receive a NOTIFY when a dataset has changed Benefits Makes use of protocols that are already on devices Works better for wireless – no longer a requirement for persistent TCP Can use any SIP/HTTP authentication mechanism Rfc822 and XML syntaxes Drawbacks May be less compact that ACAP