Data%20Manipulation

1
Data Manipulation

• Jonathan Rosenberg
• dynamicsoft

2
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

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-independe
  nt 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 doesnt 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
• 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

• 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
• 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
• Doesnt 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