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