XML Configuration Access Protocol (XCAP)

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

XML Configuration Access Protocol (XCAP)