130 likes | 233 Views
Data Manipulation. Jonathan Rosenberg dynamicsoft. Where are we. Problem Statement 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:
E N D
Data Manipulation Jonathan Rosenberg dynamicsoft
Where are we • Problem Statement • 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 • 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
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 ACAP Primitives
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 The Presence List
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” Authorization Policy
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. Notification 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” Permissions
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