XCAP Jonathan Rosenberg dynamicsoft

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

Filename? Does the xcap URI have a filename extension in it? – xcap.example.com/services/presence- lists/users/joe/mybuddies.xml – xcap.example.com/services/presence- lists/users/joe/mybuddies Proposal: with filename extension

MIME Types What MIME type is indicated in PUT request and GET response? –Application/xml, text/xml, text/plain, application/presence-list+xml, 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

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

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

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

Query v. Path Query approach: – ”] Path approach: – ”]

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

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?

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

Subscription Auth Policy If subscribeable flag is true, who can subscribe? –Spec doesn’t say Proposal –It’s a matter of local policy –We can define an xcap usage later that defines subscription permissions

XCAP Auth Changes –Added an 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

Open Issues Alignment with Geopriv Lying and Polite Blocking

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

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 can’t resolve an external reference for an exception –Exceptions don’t deny a user permissions – they allow a convenience for enumerating a long list of people to whom a rule applies

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?

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 tag

Example true basic

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!

Sphere Condition Allows a statement to apply if the presentity’s sphere has some value Dependent on inclusion of sphere in RPID Nice idea, do we need it initially? work pidf-phone

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 won’t understand security properties Proposal: remove

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

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

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

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

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

SIP Naming Common rules document can’t contain conditions for matching on users or domains –These are “using protocol” specific Need a small doc that defines sip-specific matching elements –

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!

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

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 < accept for combining purposes Proposal III –Do proposal II now, allow I later –RECOMMENDATION