XCAP

1
XCAP

• Jonathan Rosenberg
• dynamicsoft

2
Changes in Main Spec

• Removed POST usage
• Clarified the meaning of PUT for inserts vs.
  modifies
• Added AUID grammar
• Specified a grammar for xpath-style expressions
  small subset of Xpath
• Java form for vendor specific AUIDs
• Using Etags, not modification times

• No batching provided design your schemas
  carefully
• Clarified server awareness needed of the AUID and
  all namespaces in the document
• Clarified that other usages can specify auth
  policies
• Updated Examples
• No content in error responses

3
Filename?

• Does the xcap URI have a filename extension in
  it?
• http// xcap.example.com/services/presence-lists/u
  sers/joe/mybuddies.xml
• http// xcap.example.com/services/presence-lists/u
  sers/joe/mybuddies
• Proposal with filename extension

4
MIME Types

• What MIME type is indicated in PUT request and
  GET response?
• Application/xml, text/xml, text/plain,
  application/presence-listxml, new one?
• Proposal
• Application/xml when its an XML document
• Seems better than text/xml since the consumer is
  not a user rendering is not useful
• Text/plain for attributes

5
Event Package

• What is the fate of the event package?
• Many big issues
• Integrate with configuration framework?
• SyncML?
• Proposal
• Move forward with xcap, xcap-auth, xcap-list
  first, visit package second

6
Etag Scope

• Current spec associates a separate Etag with each
  XML component
• If you update one component, all ancestors and
  descendants are updated
• Problem how does the client know what those
  other etags are?
• Complex

• Proposal I
• Ancestor and descendant tags are the same as the
  new tag
• Means client can compute the tags locally
• Proposal II
• Just maintain an Etag for the whole document

7
Etag Scope

• Proposal I pros
• Allows for several users to manipulate different
  sub-trees without stepping on each others toes
• But, do we need that?
• CPCP?
• Proposal II pros
• Simpler

• Recommendation
• Proposal II

8
Query v. Path

• Query approach
• http//xcap.example.com/presence-lists/users/joe/m
  ybuddies.xml?lists/list_at_id1
• Path approach
• http//xcap.example.com/presence-lists/users/joe/m
  ybuddies.xml/lists/list_at_id1

9
Query v. Path

• Benefits of Query approach
• Makes it easy for server to figure out where doc
  ends and elements begin
• Benefits of Path approach
• Hides implementation details
• Works better with existing equipment
• Query strings in PUT
• Cache treatment of query parameters

• Recommendation
• Path Approach

10
Error Reporting

• Current revision has no special error reporting
• Operations which cause invalid schema return 409
• Giving details on error is unlikely to help
  doubtful an automata can recover
• However, there is a recoverable error
• Data interdependencies setting a URI that
  already exists
• Client should retry with new URI
• How to indicate this?
• New response code yuck
• Some kind of XML in the body of the 409
  allowed/possible?

11
XCAP List

• Changes in this revision
• Made it about generic resource lists left hooks
  for various actions to be taken against the
  list
• Added support for external references to other
  lists described by an XCAP URI

12
Subscription Auth Policy

• If subscribeable flag is true, who can subscribe?
• Spec doesnt say
• Proposal
• Its a matter of local policy
• We can define an xcap usage later that defines
  subscription permissions

13
XCAP Auth

• Changes
• Added an ltexceptgt clause, so you can except a
  user, domain or list
• Removed boolean operators from accept-if
• Removed rule permissions
• Remove transformational permissions
• Removed requested-namespace, requested-element,
  requested-tuple, duration accept-if conditions
• Show-tuple selects a tuple by tuple class, not id
• Removed show-values
• Removed compound permission AUID later
• Content permissions are applied BEFORE
  composition process

14
Open Issues

• Alignment with Geopriv
• Lying and Polite Blocking

15
Why is Alignment Good?

• Geolocation and presence are intimately related
• We want to be able to deliver geoloc information
  in presence
• Placetype is a start!
• Further enhances the SIMPLE value proposition

16
Exceptions

• Exceptions need to be treated carefully to work
• Excepting a user from is useless its easy for
  a user to get a new name
• You have to drop an entire statement if you cant
  resolve an external reference for an exception
• Exceptions dont deny a user permissions they
  allow a convenience for enumerating a long list
  of people to whom a rule applies

17
Exceptions

• Example
• Allow example.com except Bob
• Allow example.com except Judy
• If I have both these rules, and Bob subscribes,
  is he allowed?
• YES!

• Matching operations need to be carefully
  specified
• Foo.example.com same as example.com?
• Geopriv has decided not to do exceptions
  initially
• If we want alignment, we need to drop them too
• What does the group think about this?

18
Conditions

• Current xcap-auth has conditional permissions
• Accept-if
• But, conditions can make sense for any permission
• Better alternative
• All conditions are present in the ltapplies-togt tag

19
Example
ltstatementgt ltapplies-togt ltanonymousgttruelt/an
onymousgt lt/applies-togt ltaccept/gt
ltshow-elementgtbasiclt/show-elementgt lt/statementgt
20
Validity Condition

• Specifies the duration over which the statement
  applies
• Allows the server to ignore permissions
  automatically, instead of forcing the client to
  remove on expiration
• Client may not be connected
• Assures privacy safety
• Good idea!

21
Sphere Condition

• Allows a statement to apply if the presentitys
  sphere has some value
• Dependent on inclusion of sphere in RPID
• Nice idea, do we need it initially?

ltstatementgt ltapplies-togt ltspheregtworklt/spher
egt lturigtsipjoe_at_example.comlt/urigt
lt/applies-togt ltshow-namespacegtpidf-phonelt/show-n
amespacegt lt/statementgt
22
Authentication Condition

• We can specify type of authentication that needed
  to be used
• BUT, will a user be able to usefully set this?
• NO
• They wont understand security properties
• Proposal remove

23
Permission Combining

• If multiple statements apply, how are permissions
  combined?
• Current spec says UNION but this only makes
  sense for token types
• Need to define rules for other types
• Boolean OR operation
• Requires TRUE to be more permissive
• Integer MAX operation
• Requires maximum to be more permissive

24
Explicit Confirmation

• Currently, a watcher is pending if there are no
  matching statements
• Might want to explicitly specify that I should
  always be asked to confirm subscriptions from a
  user (I.e., winfo)
• To do this, would add confirm-subscription
  boolean

25
Actions vs. Transformations

• Terminology issue only
• Geopriv has
• Actions things to do if this statement matches
• Transformations ways to change data if this
  statement matches
• XCAP has
• Acceptance policy whether or not subscription is
  accepted
• Content Policy data to send
• Proposal to use geopriv terminology
• More general
• Consistent with other policy work
• Also indicate in XML

26
Unified Document Structure
Common Rule
SIP Naming
GEOPRIV Doc
SIMPLE Doc
Geopriv Rule
XCAP Auth
27
Common Rule Content

• Model Definition
• Additive Permissions
• Rule Structure
• Conditions
• Validity, sphere, uri, domain, anonymous
• Actions
• Accept subscription, confirm subscription
• Transformations
• NONE defined data specific
• Generic Terminology
• PT Presentity/Target

28
SIP Naming

• Common rules document cant contain conditions
  for matching on users or domains
• These are using protocol specific
• Need a small doc that defines sip-specific
  matching elements
• ltsip-urigt
• ltdomaingt

29
XCAP Auth Content

• Normative reference to common rule content and
  SIP URI doc
• Defines the transformational permissions
• Show-element, show-namespace, show-contact,
  show-note, show-all
• Defines the supported permissions application
  usage
• Will be a much shorter document!

30
Lying

• Per list discussion, specifying lying policies in
  XCAP is out
• Will be too much flexibility needed
• Alternative
• Client publishes false tuples
• Server publishes false tuples
• XCAP policy selects the appropriate tuple by class

• Problem
• For server case, how does client know which tuple
  to select?
• Provisioning xcap usage?
• User does it manually
• Proposal
• Xcap usage as a follow on activity

31
Polite Blocking

• Problem
• Currently, no clear way to do polite blocking
• Need this in first rev
• Proposal I
• Accept the subscription and use lying to send
  them a fake tuple

• Proposal II
• Change accept
• Make it subscription-decision with values
  accept and politely-block
• Politely-block lt accept for combining purposes
• Proposal III
• Do proposal II now, allow I later
• RECOMMENDATION