XML Configuration Access Protocol XCAP Jonathan Rosenberg dynamicsoft

XML Configuration Access Protocol (XCAP) Jonathan Rosenberg dynamicsoft

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

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?

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

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

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

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

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: #

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

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

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?

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

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?

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

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

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: <escape-encoded-HTTP-URI>@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

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?

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

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 SHA 1 directly

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

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

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

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