Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching)

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 12 Jun 2003 16:19:03 -0700

> 
> XCAP as currently proposed sort of does this, but it uses the 
> URL instead of a body, to identify where the change is to be 
> placed. For example, adding a new entry to a <list> element 
> with a "name" attribute set to "friends" would look something 
> like this (the exact Content-Type to use is still being 
> worked out, so ignore it):
> 
> 
>    POST 
> http://xcap.example.com/services/presence-lists/users/bill/fr.
xml?presence-l
ists/list[@name="friends"] HTTP/1.1
   Content-Type:text/plain
   Content-Length: ...

   <entry name="Bill" uri="sip:[email-masked]">
     <display-name>Bill Doe</display-name>
   </entry>

POST has some opponents in the IETF for new defined arbitrary semantics
(although it's widely accepted for custom work, just not for standard
protocols).  You may recall the "going postal" ID by Cohen in 1998.  

An alternative to putting the presence list information on the end of the
URL is to put it in the body.  THen the custom code only needs the body of
the special POST request to handle it.

Lisa

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 12 Jun 2003 16:19:03 -0700

xml?presence-l

Lisa

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Jun 2003 16:51:43 -0500

Lisa Dusseault [mailto:[email-masked]] writes:

> I would recommend the following (and you would likely get
> support or assistance from other WebDAV implementors in
> defining and developing this):
>  - Define a MIME type for an XPATH-based modification to an 
>    XML document. Perhaps this MIME type exists already --
>    a stylesheet type? 

XCAP as currently proposed sort of does this, but it uses the URL
instead of a body, to identify where the change is to be placed.
For example, adding a new entry to a <list> element with a "name"
attribute set to "friends" would look something like this (the
exact Content-Type to use is still being worked out, so ignore it):

   POST
http://xcap.example.com/services/presence-lists/users/bill/fr.xml?presence-l
ists/list[@name="friends"] HTTP/1.1
   Content-Type:text/plain
   Content-Length: ...

>  - Define a method like PATCH or PUTPATCH to send this document to the
>    resource to be modified

We're actually using POST. If you look at the example above, you can
sort of see why: performing a GET on the URL specified would retrieve
the entire list, not just a single element of the list. Since calling
PUT(x) with a document followed immediately by GET(x) would not yield
the same document, it seems that PUT would be the wrong choice.

Personally, I'm a bit loathe to propose any new HTTP methods to
solve any XCAP issues, because the ability to use off-the-shelf
HTTP servers is very compelling.

>  - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, 
>    and WebDAV PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the
>    DeltaV CHECKOUT/CHECKIN to create a working resource in a
>   'sandbox' while the PATCHes are applied.

So, it sounds like you're favoring, at a high level, a
lock/copy/munge/move/unlock approach.

Actually, that's pretty nice, because it also solves another problem
we had with transaction rollbacks. If something goes wrong in the
munging stage, you can just delete the copy instead of moving it
back to the location of the original.

/a