Review of XCAP -- extensions to HTTP for configuration access

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

XCAP is intended to provide access to configuration documents stored in  
XML on an HTTP server.  These configuration documents might be buddy  
lists, virtual conference room configuration, presence documents (for  
more complex presence than "online/offline"), or really anything.  The  
XCON working group is already looking at XCAP in addition to SIMPLE,  
and one could imagine SIP and SIPPING working groups using it next or  
spreading outside the SIP area.

The requirement to extend HTTP came from the observation that  
configuration documents often undergo small changes, or applications  
may be interested only in small pieces of the document.  For example,  
an application might change the buddy list document by adding a single  
buddy to a list of 200, or an even smaller change might be to change  
the buddy's email address element value. A client in a conference might  
want to retrieve the video policy from the policy configuration  
document without downloading all the floor control information.

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.

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?

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.

Lisa

Received on Monday, 15 November 2004 18:11:13 UTC