XCAP

1. XCAP Jonathan Rosenberg dynamicsoft

2. Agenda • XCAP Base • XCAP List • XCAP Event Package • XCAP Authorization Usage • Presence Data Model • XCAP Multiple Inserts

3. XCAP Base Almost There!

4. ISSUE 1: Schema Awareness Only validation ISSUE 2: Positional Insertion Added ISSUE 3: PUT v. POST PUT Client sets data ISSUE 4: Separators ~~ ISSUE 5: Multiple Insertions Deferred ISSUE 6: Select by Text No ISSUE 7: Unique Steps Required ISSUE 8: Etag Scopes Document ISSUE 9a: Namespace Discovery Through extension usage ISSUE 9b: Etags useless for insert Documented XCAP Base

5. AU specifies uniqueness constraints XCAP servers don’t do referential integrity Resource interdependencies defined Removed <mandatory-ns> Multiple xcap root ok; no information carryover Added escape coding Reworked error report document Capabilities application usage Changed MIME type names Addressed “do we need filename” issue Added guidelines for app usages Other Changes

6. Issues Raised in WGLC • DELETE Idempotency • XPath Namespace Context • ETag and DELETE • Caching

7. DELETE needs to be idempotent Won’t be for positional deletions Similar issue with insertions Solution URI has to have two properties Identifies one resource before delete Identifies no resource after Inverse of insertion DELETE Idempotency   <foo>      <bar> contenta </bar>      <bar> contentb </bar>      <bar> contentc </bar>    </foo> DELETE foo/bar[2]   <foo>      <bar> contenta </bar>      <bar> contentc </bar>    </foo> DELETE foo/bar[2]   <foo>      <bar> contenta </bar>   </foo>

8. What is the namespace context used for evaluating a step? Default namespaces Element and attribute matching XPath 1.0 Namespace from evaluation context Default is null How to handle this case XPath Namespace Context <foo> <bar xmlns=“NS1” xmlns:ns1=“NS1”/> <bar xmlns=“NS2” xmlns:ns2=“NS2”/> </foo> Select this foo/ns2:bar

9. Etag is associated with a resource (URI) After DELETE, the resource doesn’t exist Presumably 200 OK doesn’t carry Etag Thus, you lose “track” of document after DELETE Options Document limitation Put in Etag anyway Empty resources Empty Resources A resource “exists” as long as parent exists and is not empty To delete, you PUT it to empty To insert, you modify from empty to content ETag and DELETE

10. Pros Makes etags useful for all operations Cons Hack May interact with other mechanisms Complicates simple cases Proposal Document limitation Empty Content

11. Caching • XCAP says nothing about cache control • It should • Proposal • Not really different than other content • If you allow caching, it might be stale • PUTs may be against sub-resources, making staleness likely – won’t be picked up by server processing PUT

12. XCAP List Lists, lists and more lists

13. ISSUE 1: Scope of entry-ref XCAP Root ISSUE 2: URI of <entry> attribute or child Attribute ISSUE 3: name or URI as <entry> index URI Canonicalization defined ISSUE 4: Index document Added RLS Services document Server generates composite document in global tree Picks off docs in specific place in user tree Somewhat obviates need for XCAP directory XCAP List

14. <?xml version="1.0" encoding="UTF-8"?> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists“ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service uri="sip:mybuddies@example.com"> <resource-list>http://xcap.example.com/resource-lists/ users/joe/index/~~/ resource-lists/list%5b@name=%22l1%22%5d </resource-list> <packages> <package>presence</package> </packages> </service> <service uri="sip:marketing@example.com"> <list name="marketing"> <rl:entry uri="sip:joe@example.com"/> <rl:entry uri="sip:sudhir@example.com"/> </list> <packages> <package>presence</package> </packages> </service> </rls-services>

15. Issues Since WGLC • Embedded vs. External Resource Lists • Simpler structure for RLS services doc • Support for “membercode” from draft-hiller-uri-list-index

16. Embedded v. External Lists • RLS Services doc allows resource lists to be specified by value or reference • Reference has to be within same XCAP root • Jari asks – why both? Why not just by reference? • Desire to have a self contained buddy list document • Avoid referential integrity ugliness for simple cases

17. Simpler Structure • Jari asks, “can’t we just define each RLS service by its resource list”? • I don’t think so • RLS service uses a lot of provisioned data • Resource list is just one piece • Spec also defines allowed packages • Other things for the future • Index to authorization policies • Back end subscription policies • Keep it extensible

18. Draft-hiller-uri-list-index proposes a small payload for specifying subscriptions to list subsets Requires each list entry to have an integral index Currently, resource lists don’t have this index Cannot be added, schema doesn’t support that type of extensibility Options Ignore Add attribute extensibility Add “membercode” now Support for Membercode

19. Ignore Not a chartered item Feature creep Add extensibility Allow it later Needs to extend the app usage in addition to the schema Add membercode now Con: similar to the “name” attribute we just removed! Pro: will be work to add later Proposal Add attribute extensibility Membercode choices

20. XCAP Package/Diff Change is good

21. Major Changes! Unified with Config Framework Draft-ietf-sipping-config framework Event package Event header parameters to specify what you want Draft-ietf-simple-xcap-package XCAP diff format Can be used as a MIME type in config package Benefits of unification Single bootstrapping and data discovery framework Allows for bootstrapping to start and stop at various layers XCAP Package

22. Bootstrapping points • Client knows its username, password, but not applications • SUBSCRIBE sip:user@domainEvent: sip-profile;profile-name=application • Client knows username, password, and the specific app usage • SUBSCRIBE sip:user@domainEvent: sip-profile;profile-name=application; app-id=resource-lists • Client knows the specific document • SUBSCRIBE sip:user@domainEvent: sip-profile;profile-name=application; app-id=resource-lists;document=“user/index”

23. XCAP Diff Format

24. Directory allows discovery of documents on startup Config framework allows discovery of documents on startup SUBSCRIBE to user@domain with Event sip-profile and profile-name of app and Accept of xcap-diff Returns an xcap-diff document listing all of my documents and global documents of relevance Same function as directory Proposal: directory not needed Relationship to directory

25. XCAP Auth Usage Picking up the Pieces in light of a Data Model

26. Problem <sphere> as a condition can be ambiguous What tuple are we talking about? Previously: if ambiguous, condition fails Data Model Impact <sphere> is a presentity characteristic There is only one per document Problem eliminated Issue A: Sphere interpretation

27. Problem Do we do authorization first, then composition, or the opposite? Do our documents define composition Data Model Impact Defines a specific data processing sequence Separate composition control [aka – how you land at a concrete document] from privacy [how you strip it down] Problem eliminated Issue B: Sequencing

28. Problem What happens if document, after privacy, has tuples which don’t differ much? Do we mandate re-combination? Optional? How to do it? Data Model Impact Post-filtering composition is done Guided by composition policy (TBD) Problem solved Issue C: Post Privacy Composition

29. Problem Can authorization policy allow me to give conflicting information to different watchers? Previous Answer Yes – presence doc has inconsistent tuples You pick which one to send based on class Data Model Impact Each service or device can be represented only once Thus, a document cannot have conflicting data The problem is thus relegated entirely to composition policy Specifies which inputs to include in a document Problem solved Issue D: Different Docs to Different Watchers

30. Problem Currently, authorization policy jointly specifies how to process subscription (accept, block, polite block) from how to process data (transformations) Should they be split Considerations Do the same conditions make sense? Time of day [yes] Watcher [yes] Presentity state [?] Service state [?] Device state [?] When do we need the policy Upon subscription Upon input state change Issue E: Separate subscription from document processing

31. Considerations Action currently includes both Polite block affects data Overhead If they are separate, users will normally need to set both Continuum Rejection of a subscription is just the extreme end of a privacy continuum Data Model Impact Data processing doesn’t include subscription acceptance/rejection - would seem to argue for split Polite blocking is actually acceptance plus a specific composition policy! Issue E:

32. Logically, there are three policy documents What to do when you get a SUBSCRIBE “Subscription Policy” How to generate a document when an input changes “Composition Policy” How to filter a document for privacy “Privacy Policy” Each policy document has conditions, actions and transformations specific to it Each policy document has conditions, actions and transformations applicable to all Use XML namespaces to indicate which conditions, actions, transformations are for subscription, composition or filter policy Proposal: Logical Split, Physical Join

33. Subscription Policy • Conditions • Identity, sphere, validity • Actions • Reject, confirm, accept • Transformations

34. Composition Policy • Conditions • Identity, sphere, validity [types of inputs, numbers of inputs, etc.] • Actions • Polite-block, [concatenate, etc.] • Transformations

35. Privacy Policy • Conditions • Identity, sphere, validity • Actions • Transformations • See later slides

36. Problem Current document makes transformations conditioned on tuple type Two layer conditions ugly Henning proposed policy documents apply to tuples Data Model Implication Policy documents apply to processing of presence document Can condition policy document on existence of specific service, device or their characteristics Can specify transformations that apply to specific service, device, presentity Proposal Punt per-tuple privacy Issue F: What does document apply to

37. Provide tuples of particular schemes/class/type? Provide all RPID elements? How to provide note? Document-wide? Per-tuple? RPID elements by name and class/URI scheme/type of tuple? Not a data model issue (mostly), a scope issue Use cases really unclear Proposal Absolute minimum for now Provide services by URI or scheme Provide devices by device ID Provide attributes by name Not on a tuple by tuple basis Issue G: What kind of privacy transformations do we want?

38. Motivating Use Cases • Give Bob information on my voip service, but not my telephony service • Allow Jane to see my Vonage service, but not my work service • Don’t show anyone what I’m doing right now

39. Presence Data Model What is a tuple anyway?

40. Motivation • Need to have a common understanding of what presence documents really mean in order to achieve interoperability • Consistent understanding and interpretation of our various extensions • Only one way to interpret a document • Many of our drafts are caught in loops due to lack of understanding

41. Tuple Design Team • Points of Debate • One vs. Many Presentity • Devices or not • Resources and Capabilities as Device Information • Correlation of services across devices • Meaning of “idle”

42. Model allows one presentity per document Inherently presence models one presentity Some concerns about inability to retain conflicting information from multiple sources Proposals to handle conflicts at attribute level Design team conclusion Retain current model of one per document One vs. Many Presentity

43. What some folks thought of as a device previously is now called a service What is the definition of a device? How to model distributed devices? Bluetooth headset + mobile phone Design team conclusion Devices are useful, we should keep them Not clear what does in them Not clear how to define them Devices or Not

44. Is it useful to say certain things about devices CPU Memory Bandwidth Screen size Video camera, speakers Problem: application may not get access to these resources If it does, they become service characteristics Design Team Conclusion Devices not useful for conveying resource and capability information Resources and Capabilities

45. Is it useful to know that Two services run on the same device A service runs across multiple devices Former most interesting Helps in selecting a service because a human can extract service preference from device correlation Send an SMS to the device I just called Design Team Conclusion Correlation useful Service states cannot be automatically inferred from other services on the same device Correlation

46. Model proposes idle interpretation is dependent on service, device or presentity Device: no input into device (meaning in existing IM systems) Service: no input into service Presentity: no input to person? Other approaches Have it mean probability of responding How to measure? Have it be specific to a type of input Keyboard Mouse No conclusion Meaning of Idle

47. Multiple Inserts • Relegated to a separate draft • draft-rosenberg-simple-xcap-multiple-00.txt • Defines proposal we’ve been debating on the list

48. Issue – referential integrity We have a few places where one document contains a reference to another Server doesn’t guarantee referential integrity now – very hard Doesn’t fit well with “reject if not good” model Multiple inserts would allow server to check referential integrity Client would need to PUT something so that result is fully consistent Allow app usages to specify referential integrity constraints Takes us a major step closer to a DB protocol Is that what we want? Is this the right group to do it? Multiple Inserts