XCAP

1. XCAP Jonathan Rosenberg Cisco Systems

2. 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

3. 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

4. Example Client Server <hello xmlns=“NS1”> <this xmlns:bar=“NS2”> <bar:is xmlns:test=“NS3”/> </this> </hello> GET http://doc/~~/hello/this/bar/namespace::* <bar:is xmlns=“NS1” xmlns:bar=“NS2” xmlns:test=“NS3”/> Only GET Allowed!

5. 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

6. Example <root> <el1 att="first"/> <el1 att="second"/> <!--comment --> <el2 att="first/> </root> <root> <el1 att="first"/> <el1 att="second"/> <!--comment --> <el1 att="third"><el2 att="first/> </root> PUT root/el1[@att=“third”] <el1 att="third"/>

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

8. 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

9. Alternative Proposals for GET • Use Canonical XML • Instead of getting namespace bindings, those bindings are returned as a result of a normal GET anyway

10. Example <?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> GET ../~~/root/element/ <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>

11. 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

12. 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

13. 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…

14. 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

15. 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

16. 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