XML Configuration Access Protocol (XCAP)

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 ACAPs data
  synchronization capabilities
• Was dependent on TCP connection state

3
Recap IETF 56

• Group reactions
• Why have we dredged up this ancient protocol?
• Dont 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 doesnt 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))
  ltgt foo
• The GET returns the begin/end tags, the PUT
  doesnt include them
• You cant 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?
• Sipjoe_at_domain information on desired document
  is present as an event header parameter
• Sipltescape-encoded-HTTP-URIgt_at_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