Re: Review of XCAP -- extensions to HTTP for configuration access

At 10:09 AM -0800 11/15/04, Lisa Dusseault wrote:
>I haven't seen XCAP 
><http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-04.txt> 
>announced or discussed on these lists.  I'll try to give an 
>overview, but please forgive me if there are any inaccuracies.  I 
>haven't had the bandwidth to follow the SIMPLE list and this is not 
>in my job scope so while I've been meaning to invest some time in 
>understanding it better, I haven't found much of that time.
>
>XCAP is being developed in the SIMPLE working group.  (I have a 
>problem with this process, because XCAP is a substantial extension 
>to HTTP, and this feels like it's being buried in a group working on 
>mostly non-HTTP protocols -- thus I'm hoping to see some discussion 
>on HTTP lists.)

The intent of this was not to create a substantial extension to HTTP, but a
profile.  That is, rather than doing a full XPATH-based application protocol,
they chose instead to limit the structures of resources to pure hierarchies
so that standard HTTP mechanisms could be applied.

<snip>

>To achieve this partial access, XCAP changes HTTP URLs and 
>(depending on your outlook) the semantic of the PUT body.  Each 
>configuration document has a HTTP URL, such as 
>"http://xcap.example.com/users/lisa/buddylist.xml".  XCAP also 
>allows URLs to address XML elements or attributes inside the XCAP 
>document, by putting XPATH-based syntax on the URL -- turning every 
>XML element into an addressable resource.  E.g

I don't think it changes the HTTP URI scheme.   I also believe that 
its model for
how resources relate is within the HTTP mechanism.  It is parallel in many ways
to HTTP driven by relational databases rather than files.  It takes a 
bit of head-twisting
to see relational database resources (especially view-based ones) as 
HTTP resources,
but there is nothing to rule it out; that some resources may also be stored
in XML documents doesn't mean that they can't be resources in their own right.

>http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
>
>In this URL, the ~~ separator indicates the end of the regular 
>meaning of the HTTP URl, and the beginning of the XPATH-like parsing 
>which leads to a certain entry where name = "friends" (I think).
>
>XCAP servers support GET, PUT and DELETE against these new types of 
>URLs; these operations modify parts of the configuration document.  
>Also note "an XCAP server MUST maintain entity tags for all resources".
>
>Current status:
>  - Document formats for XCAP are defined in separate drafts, e.g. 
><http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt>
>  - XCAP itself finished Working Group Last Call in August, thus the 
>SIMPLE working group believes it is complete.
>
>I'm concerned about two main areas myself:
>  - The behavior of these resources on intermediaries, particularly 
>caches and write-through caches.
>  - The interaction or compatibility between XCAP and other HTTP 
>extensions.  To take WebDAV for an example, is a server supposed to 
>be able to lock every one of these new resources?  Is there any 
>chance that two independent servers that support XCAP and WebDAV 
>could do so in the same way?

It was a goal of the SIMPLE working group (at least one point) to move to
a locking mechanism based on WebDAV over time.  That requires
resource level locking that looks at least initially to be within WebDAV's
protocol scope.  Many current implementations won't work (since their
locking granularity is file-based, rather than seeing files as "XML databases"
of resources), but that isn't a protocol problem.  Obviously, we 
can't really answer
that question long term until there is a draft, but it was within the goals of
the group as I understand them.

>I wouldn't be surprised if members of these lists can come up with 
>other problems, because I feel this approach is headed straight at a 
>deployment/interoperability minefield.  If, on the other hand, 
>people review XCAP and do not find problems, it would be a service 
>to let me, Jonathan, or this list, know of positive reviews by HTTP 
>experts.
>

Reviews are good, and careful thought on it will be much appreciated.  Please
do start from the idea that XCAP's intent is *not* to change HTTP, though,
and highlight places where the drafts are unclear on whether or not it
proposes a change or where the drafts do present incompatible changes.
The working group is aware that the e-tags requirement is not present
in HTTP, but sees it as appropriate for its profile.
			regards,
				Ted Hardie

Received on Monday, 15 November 2004 20:30:34 UTC