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

5. Other Changes AU specifies uniqueness constraints XCAP servers don’t do referential integrity Resource interdependencies defined Removed 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

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

7. DELETE Idempotency 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 contenta contentc DELETE foo/bar[2] contenta contentb contentc DELETE foo/bar[2] contenta

8. XPath Namespace Context 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 <bar xmlns=“NS1” xmlns:ns1=“NS1”/> <bar xmlns=“NS2” xmlns:ns2=“NS2”/> Select this foo/ns2:bar

9. ETag and DELETE 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

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

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. XCAP List ISSUE 1: Scope of entry- ref –XCAP Root ISSUE 2: URI of attribute or child –Attribute ISSUE 3: name or URI as 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

14. <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"> http://xcap.example.com/resource-lists/ users/joe/index/~~/ resource-lists/list%5b@name=%22l1%22%5d presence presence

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. Support for Membercode 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

19. Membercode choices 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

20. XCAP Package/Diff Change is good

21. XCAP Package 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

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

23. XCAP Diff Format

24. Relationship to directory 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

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

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

27. Issue B: Sequencing 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

28. Issue C: Post Privacy Composition 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

29. Issue D: Different Docs to Different Watchers 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

30. Issue E: Separate subscription from document processing 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

31. Issue E: 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!

32. Proposal: Logical Split, Physical Join 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

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. Issue F: What does document apply to 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

37. Issue G: What kind of privacy transformations do we want? 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

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. One vs. Many Presentity 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

43. Devices or Not 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

44. Resources and Capabilities 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

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

46. Meaning of Idle 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

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. Multiple Inserts 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?