1. Jonathan Rosenberg dynamicsoft
Data Manipulation
Jonathan Rosenberg
dynamicsoft

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

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

4. 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)

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

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

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

8. 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”

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

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

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

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

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