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

From: Lisa Dusseault <[email-masked]>
Date: Mon, 15 Nov 2004 10:09:54 -0800

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Nov 2004 12:29:47 -0800

At 10:09 AM -0800 11/15/04, Lisa Dusseault wrote:
>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).
>
><http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt>
>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.

>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