Post on 06-Jan-2016
description
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