XCAP

Jonathan Rosenberg

Cisco Systems

History

• -07 was IESG approved and now in RFC-ED queue in normative hold on xcap-diff

• Several small bugs reported against XCAP and a major issue raised on namespace fragments in PUT– How to know namespace prefixes in content of body?

• Proposal on list to– Yank from queue (not done yet)– Revise and republish to

• Fix minor bugs reported• Address extensibility issue• Fix namespace problem

Changes in -08

• Added URI extensibility– There “in principle” previously – unknown URI

would be rejected with 404– Still true, but URI grammar now has hooks– Negotiation of extensions through existing

xcap-caps mechanism

• Added namespace::* selector from xpath for learning namespaces

Example

<hello xmlns=“NS1”> <this xmlns:bar=“NS2”> <bar:is xmlns:test=“NS3”/> </this></hello>

Client Server

GET http://doc/~~/hello/this/bar/namespace::*

<bar:is xmlns=“NS1” xmlns:bar=“NS2” xmlns:test=“NS3”/>

Only GET Allowed!

Additional Changes

• Clarified 200 vs. 201– 201 on Creation– 200 on Insertion

• URI reference to 3986• Clarified – SHOULD NOT escape code ~~, but

normalization happens for comparison (ref 3986)• Removed schema-instance declarations• Clarified insertion rules relative to other elements,

comments and whitespace: earliest last– After the last element with the same name, but before any other

elements, but after any whitespace/comments

Example

<root> <el1 att="first"/> <el1 att="second"/> <!--comment --> <el2 att="first/></root>

PUT root/el1[@att=“third”]

<el1 att="third"/>

<root> <el1 att="first"/> <el1 att="second"/> <!--comment --> <el1 att="third"><el2 att="first/></root>

Changes

• Document selector configuration simplified– XUI = SIP AOR for SIP applications– Single document usages, doc is called “index”– Sub-directories not recommended

• Cannot have document and subdirectory with same name

Pros/Cons of Namespace Proposal

• Client needs to do a GET to obtain namespaces in scope at insertion point and THEN do a PUT with new content– Need to worry about namespace bindings

changing between GET and PUT– Can cache bindings, though

• Cannot construct static PUTs– i.e., map a UI command “add buddy” to an

HTTP PUT with a URI that is a function of the usage, filled in with template data from UI

Alternative Proposals for GET

• Use Canonical XML– Instead of getting namespace bindings, those

bindings are returned as a result of a normal GET anyway

Example

<foo:element xmlns:bar="ns2" xmlns:foo="ns1"> <bar:element > <bar:child xmlns:b="ns3" attr="value" b:attr="value"> </bar:child> </bar:element></foo:element>

GET ../~~/root/element/

<?xml version="1.0" encoding="UTF-8"?> <foo:root xmlns:foo="ns1" xmlns:bar="ns2"> <foo:element> <bar:element> <bar:child attr="value" b:attr="value" xmlns:b="ns3"/> </bar:element> </foo:element> </foo:root>

Canonical Example Pros/Cons

• Unfortunately changes nothing for PUT – still need to do GET first, still issues with conditional PUT

• A little cleaner• Getting an element and its namespaces happens in one

shot, BUT no way to get JUST namespaces – problem for elements with many children

• Does GET(PUT(X)) == X? – Depends on equality – from XML perspective I believe so

• Requires XCAP server to do canonicalization in all GET responses

Making the PUT Easier

• Proposal 1: An app usage can require namespace prefixes to be hashes of namespace URI– Makes all prefixes “well-known”– No referential integrity problem, unlike namespace

prefix munging– But kind of kludgey

• Proposal 2:– PUT bodies contain namespace declarations – don’t

depend on in-scope bindings– Will pollute document with lots of redundant binding

declarations, but otherwise works with existing spec

Recommendation

• Reject canonical XML approach– Requires getting all elements to just get

namespace bindings

• Go for proposal 2 for blind insertions– Document this use case

• But, we still have a problem with blind insertions on simultaneous writers…

The Insertion Problem in XCAP

• XCAP is fundamentally about mapping XML components to resources

• In current spec, if an element or attribute doesn’t exist in the document, neither does its corresponding HTTP resource– This is the “natural” definition

• Big drawback: an insertion is a resource creation and thus resource had no etag– Makes it impossible to do conditional insertions

• This was a conscious group choice, but it is proving to be a huge practical mess

Implications of Unconditional Insertions

• XCAP server needs to return what document etag was prior to insertion– Requires normative reference to xcap-diff

• If this doesn’t match client copy, client needs to– Undo its change– Do a PUT to repair document– Deal with possibility that this PUT might fail

• Criticisms on this problem continue

Proposed Change

• An HTTP resource if its parent exists in the document

• If the parent exists in the document but the component doesn’t, the resource is considered empty– A GET of it would return a document with no content– Kind of hokey

• But, all element insertions end up being HTTP modifications, not creations, so etags can be used

• Eliminates the need for xcap-diff at all as part of xcap core