XCAP

1. XCAP Jonathan Rosenberg dynamicsoft

2. 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 Changes in Main Spec

3. Filename? • Does the xcap URI have a filename extension in it? • http:// xcap.example.com/services/presence-lists/users/joe/mybuddies.xml • http:// xcap.example.com/services/presence-lists/users/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-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

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

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

8. Query v. Path • Query approach: • http://xcap.example.com/presence-lists/users/joe/mybuddies.xml?lists/list[@id=“1”] • Path approach: • http://xcap.example.com/presence-lists/users/joe/mybuddies.xml/lists/list[@id=“1”]

9. 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 Query v. Path

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 doesn’t say • Proposal • It’s a matter of local policy • We can define an xcap usage later that defines subscription permissions

13. XCAP Auth • Changes • Added an <except> 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 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

17. 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? Exceptions

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 <applies-to> tag

19. Example <statement> <applies-to> <anonymous>true</anonymous> </applies-to> <accept/> <show-element>basic</show-element> </statement>

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 presentity’s sphere has some value • Dependent on inclusion of sphere in RPID • Nice idea, do we need it initially? <statement> <applies-to> <sphere>work</sphere> <uri>sip:joe@example.com</uri> </applies-to> <show-namespace>pidf-phone</show-namespace> </statement>

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 won’t 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 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 • <sip-uri> • <domain>

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

31. 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 Polite Blocking