1. XML Configuration Access Protocol (XCAP) Jonathan Rosenberg dynamicsoft

2. Recap: IETF 56 I proposed SEACAP as a way to meet data manipulation requirements –SOAP encoding of ACAP –Specify ACAP dataset classes for buddy list and authorization data –Some issues with using ACAP’s data synchronization capabilities Was dependent on TCP connection state

3. Recap: IETF 56 Group reactions: –Why have we dredged up this ancient protocol? –Don’t like the data model –Too complicated –What about webdav? –What about SNMP?

4. A Change in Direction Really need to simplify Really need to modernize Really nice to make data schema independent from the protocol

5. Introducing XCAP Based on HTTP No SOAP Client addresses XML document components (elements, attributes) using Xpath HTTP primitives – PUT, POST, DELETE, GET provide ability to modify any component of document on the server HTTP preconditions (If-Unmodified-Since) allow you to provide atomic read/modify/write SIP event package lets you know when the data on the server has changed

6. Introducing XCAP Application Usage –Like a package in sip events –Specifies a specific application usage of XCAP –Mainly a schema definition, also some additional information, like additional data constraints and authorization policies Submitted a draft on an application usage for buddy lists Pending I-D on authorization policy

7. Benefits of XCAP Clean separation of data and protocol –Buddy list and authorization policies just normal XML schema –Can be used in other places besides XCAP Example: filtering Very simple protocol Applicable to a lot of problems Good over-the-air efficiency

8. Issue 1: Separating document and component identifiers HTTP URL currently has two pieces – one that identifies the document, and a query string that identifies the component of the XML document Should we instead use a “#” to separate them? Should we try not to separate these at all – directory structure naturally extends into XML document? –Not clear the latter is achievable Proposal: #

9. Issue 2: Multiple components GET, PUT and POST can only address a single XML component As such, there is no easy way to set a number of separate components in one atomic transaction –Could set the least common subtree – expensive! We do have a requirement for allowing an atomic operation on multiple data elements Proposal 1: keep the requirement, only way to do it is least common subtree. Practically speaking, not a common case Proposal 2: Allow body to contain multiple components – need some kind of wrapper

10. Issue 3: Meta-Data There is a lot of useful XML meta-data –Number of children of an element –Number of attributes of an element Xpath provides functions to obtain this XCAP doesn’t allow them to be present in request URI Question: do we allow them? Will expand the scope of what can be in the request URI by a lot – no longer just location path

11. Issue 4: Server awareness Currently, the spec says a server needs to understand the application usage against which requests are made –That is, server needs an upgrade for a new app May be possible to lift this for application usages which –Have no computed data –Have no additional data constraints –Follow the baseline authorization policy Do we want this?

12. Issue 4.1: XML Extensibility Application usage defines the schema, which the server needs to know What if schema defines extensibility, and a user adds data outside of the defined schema, using a namespace/schema not understood by server? Proposal: direct extension of previous issue – server needs to understand all of the namespaces

13. Issue 5: Server Authorization In ACAP, authorization was built into the protocol In XCAP, I am proposing that there is a trivial default authorization policy If you want a more complex one, you need an application usage to represent the authorization policy This really simplifies the protocol a lot Is this constraint OK?

14. Issue 6: PUT vs. POST XCAP currently uses PUT on an element to replace its content, POST on an element to add a sibling to that element PUT is not quite right here, since GET(PUT(foo)) <> foo –The GET returns the begin/end tags, the PUT doesn’t include them –You can’t have them in the PUT, since they are redundant with the URI Generally, PUT feels wrong in other places we are using it –However, need to disambiguate between replace and append semantics for elements Proposal: All POST, use query string with ?replace or ?append

15. Issue 7: HEAD Draft talks about server behavior for POST, PUT, DELETE, and GET Makes no mention of HEAD –Other methods are not content specific Do we need to say anything about HEAD? –We havent said anything about the header values except Content-Type anyway Proposal: worth mentioning for completeness

16. Issue 8: R-URI in Event Package What should the request-URI look like? –Sip:joe@domain – information on desired document is present as an event header parameter –Sip: @domain – information on document is present in the URI Using user name works well with sip routing –Overlaps with username in HTTP URI –How would global documents work? Using HTTP URI seems to more accurately reflect subscribed resource

17. Issue 9: Subscribe to Multiple Documents Event package constrains subscription to be to a single document We could allow multiple-document subscriptions by allowing http URI to indicate a directory –Multi-user subscriptions still not possible Makes things a bit more complicated – do we want it?

18. Issue 10: XML Schema in Notifications Current schema is lame – uses HTTP methods to indicate what happened Should change it to indicate general changes – append, replace, delete

19. Issue 11: Signature over document Event package sends changes in the XML document Need a way to avoid divergence between client and server Package provides a signature over the canonical XML Current version uses HMAC with a fixed key –Mostly because I was tired when I wrote this Should probably use a SHA1 directly

20. Issue 12: URI list for a list XML schema for buddy list has a URI for subscribing to the list Do we want aliases, each of which identify the same list? If so, how to represent? –Comma separated list in attribute probably a bad idea when working with XCAP –Should be using an element of the list

21. Issue 13: List subscription policy Need a way to specify who can subscribe to a list SEACAP had this information as part of buddylist schema I believe it should be separate –Keep the buddy list pure – has other applications! Proposal: define an application usage for subscription authorization policy

22. Issue 14: Name and Display- Name Buddy list schema provides both a name as an attribute of the buddy element, and a display-name child element They kind of overlap –Name really to use in facilitating the Xpath expression –Display-name for human rendering Do we want both? Proposal: yes – clarify the different roles, change “name” attribute to “id” or something

23. Issue 15: Data scope Data in schema is really basic –List name –List URI –Member URI and display names Lots of other data about a user we COULD put in there We did make it extensible (its XML) Proposal: keep it basic