Subject: RE: [Simple] Thoughts on XCAP

From: [email-masked]
Date: Wed, 18 Jun 2003 11:19:27 +0300

Hi,

First of all, I don't like the idea of creating a new port for XCAP and defining it as a new protocol. To speed up the development and adoption of Data Manipulation (and potentially Conference Control), we need to be able to reuse existing HTTP stacks, for both client and server.

It isn't enough to consider only the existing server side support for Webdav. Client side support is equally (if not more) important and probably more scarce.

What about not doing batching at all? Could that be an option.

In practise:

o 1# We would have only have independent operations - no MOVE. For example, if you wanted to move a buddy from "public" authorization list to "friends", you could first ADD to friends, then delete from public. The question is: does this introduce an inconsistent state for authorization that would require locking the document in between the operations? Any other scenario that would?

o #2 If operations are such that they leave the document in an inconsistent state, you would do a highest common element replacement. This means going towards the root element of the document until reaching a node under which all of these operations were performed - then replacing the entire sub-tree. In a worst case scenario, you would end up replacing the entire document.

o #3 No batching of multiple requests. How often would you do off-line edits to authorization lists, presence-lists etc., where #2 would not be an option?

So I would still like to revisit our original requirements in order to see if we really need to go beyond the HTTP semantics, e.g., WebDav style locks etc.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Saturday, June 14, 2003 2:45 AM
> To: [email-masked]
> Subject: [Simple] Thoughts on XCAP
> 
> 
> Howdy folks,
> 	As you know from recent traffic on the list, there was an
> agreement at the Interim Meeting to accept the XCAP docs as working
> group drafts.  After that was announced to the working group, Jonathan
> asked me to take a look at them to see if there were any gotchas
> likely on the use of HTTP, XPATH, and the other components of the
> proposal.
> 	After reading the core doc and re-reading the XPATH doc,
> Jonathan, Jon, and I had a phone call earlier today to discuss the
> proposals and to talk about the conversation around this proposal that
> happened at the Interim.  First, let me say that I understand the
> approach of the group is to define a set of schemas which allows the
> manipulation of this data, but that the group intends that the data
> manipulation and transport will be out-of-band to SIMPLE itself.
> Second, let me say that I am very happy to see energy in the group
> around solving this problem, and I appreciate the work that has gone
> into hammering on this solution.  Last, let me say that I think the
> XCAP docs provide a foundation for work that the working group can
> take forward if this is the consensus of the group.
> 	There are, however, some issues that I would like to ask the
> working group to consider.  First, the IETF has in the past asked
> working groups re-using HTTP to be very careful that the semantics of
> their use fit within the semantics of HTTP (It has in particular asked
> working groups to be very careful about using "POST" as an operator to
> extend the semantics of HTTP).  Where a re-use of HTTP extended or
> restricted the semantics of HTTP, the IETF has asked that the group
> create a new uri scheme, select a new port, and describe the protocol
> in full.  The Internet Printing Protocol (IPP) and WebDav are both
> cases where this has occurred.
> 	As I read the documents at the moment, I believe that XCAP
> would fall in to this category; right now it is sufficiently different
> from the basic semantics of HTTP that it would require full
> specification, and would likely need to shift some of the "POST"-based
> semantics to other methods.  While I don't think this a bad idea
> (indeed, I suspect the resulting protocol would see reuse almost
> immediately), it is likely to take time and effort.  It may also
> require some expertise from those who are not currently core
> participants in the SIMPLE effort.  I can work with the chairs to
> help identify those resources, if required.
> 	Both Jon and Jonathan have expressed concern that taking the
> XCAP documents down that road would take more time than is practical
> for SIMPLE.  While no one really wants to re-visit a decision that has
> already been made, I wanted to make sure the working group understands
> the type of output that would likely be expected for XCAP.  I
> certainly don't want to do anything that dims the energy of the group,
> though, and I'm sure we would all like to find a way forward which
> minimizes delay.  In the call today, Jon, Jonathan, and I brainstormed
> a bit on the roads forward, and I'd like to share my view of them
> below.  I believe Jonathan will also be sending his view.
> 
> 1) Continue work on XCAP with the current set of requirements as a
>     guide.  With a strong design team in place, work to complete a
>     spec which is fully functional for SIMPLE's needs and is either
>     sufficiently general or extensible that it can be used by other
>     likely consumers of an XML-based data manipulation and update
>     protocol.  Four to six months would be the most 
> optimistic imaginable
>     timeframe for this, and it might be much longer.
> 
> 2) Shift the XCAP framework so that it fits fully within the semantics
>     of HTPP.  This likely would involve paring some requirements,
>     since locking would not be enabled.  Depending on the extent
>     to which XPATH-based URIs were supported, this might or might
>     force the fundamental unit of manipulation to always be the
>     full list, which could have an impact on wireless users.
> 
> 3) Shift the model so that the individual elements are
>     seen as collection members with specific attributes, and re-use
>     WebDav's locking and methods to accomplish the manipulation of
>     the components. This may constrain implementations in ways that
>     reduce efficiency for some operations.
> 
> 	It is unfortunate that there is no easier answer here; each
> has an engineering trade-off that requires either a shift in the
> requirements, the view of the components, or the scope of the effort.
> As the working group considers these documents and this requirement, I
> would appreciate you considering each of these trade-offs and sharing
> with the group your view and other considerations which occur to you.
> 
> 					thanks,
> 						Ted Hardie
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: [email-masked]
Date: Wed, 18 Jun 2003 10:00:44 -0700

At 8:47 AM -0700 6/18/03, Lisa Dusseault wrote:
>
>Not sure if we're all clear on this but the semantics of WebDAV MOVE is to
>move a whole document from one URL to another (perhaps overwriting an
>existing document at the target URL).  The command does not have the
>semantics of moving only partial information from one document to another.
>Neither does WebDAV have the ability to ADD only partial information to the
>body of a document although with PROPPATCH it may add/modify a single
>property on an existing document's metadata.

"Whole document", however, can also be read as "atomic resource", and
that gives some flexibility.  If you treat the "buddy list" as a collection of
buddy resources, then the individual buddy resources are atomic resources
and a MOVE can be applied to them.  Theoretically, you could also treat
each of the buddy resources as a collection of attribute resources, so
that you could move them, update them, or change the metadata on
them as atomic resources.  (Henning made some comments along these
lines a week or so ago).

The balance here is between how much work the server goes through
to manage elements of the buddy lists (buddy resources, attributes)
and how much work it goes through to (possibly assemble from parts
and then) return the list.  Which one the group optimizes needs to depend
both on the capabilities of the users and on the perceived rate of
the action.  Downloading a buddy list, making a change, and uploading
is expensive to a wireless client, but if it is a once-a-month thing,
jumping through hoops to make it possible to work on elements of
the list is a waste.  If it is three times a day, it may be critical.

In general, the right balance there will also depend on how much the 
requirement
is to update and modify hierarchically structured uniquely named 
resources (which can
be mapped in both XML and WebDav pretty easily) and how much it needs
to handle arbitrary XML structures.  The latter will definitely restrict how
well Dav can be used (either directly or as a model)

				regards,
					Ted Hardie

---

From: [email-masked]
Date: Wed, 18 Jun 2003 10:00:44 -0700

regards,
					Ted Hardie

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 18 Jun 2003 08:47:41 -0700

> It isn't enough to consider only the existing server side 
> support for Webdav. Client side support is equally (if not 
> more) important and probably more scarce.

General WebDAV client availability is actually huge-- WebDAV clients now
ship with every copy of Windows (since Win98) and Macs (since Mac OS X) and
are freely available for Unixes.  That might well help the developers of IM
clients needing to save buddy lists -- the client developer might simply be
able to use file system scripting or API capabilities to specify the
location of the remote WebDAV server and save the buddy list there as a
regular document.  That approach would definitely require the buddy list to
be one or more regular MIME type documents stored in a fully
WebDAV-compatible collection.

WebDAV client API availability is pretty good too.  C and Java libraries are
available free (and open source).  Python 2.0 ships including WebDAV client
libraries.  Even with only a bare HTTP library, it's pretty easy to put
together WebDAV client requests.

> o 1# We would have only have independent operations - no 
> MOVE. For example, if you wanted to move a buddy from 
> "public" authorization list to "friends", you could first ADD 
> to friends, then delete from public. The question is: does 
> this introduce an inconsistent state for authorization that 
> would require locking the document in between the operations? 
> Any other scenario that would?

> 
> o #2 If operations are such that they leave the document in 
> an inconsistent state, you would do a highest common element 
> replacement. This means going towards the root element of the 
> document until reaching a node under which all of these 
> operations were performed - then replacing the entire 
> sub-tree. In a worst case scenario, you would end up 
> replacing the entire document.
> 
> o #3 No batching of multiple requests. How often would you do 
> off-line edits to authorization lists, presence-lists etc., 
> where #2 would not be an option?
> 
> So I would still like to revisit our original requirements in 
> order to see if we really need to go beyond the HTTP 
> semantics, e.g., WebDav style locks etc.
> 
> Regards,
> Hisham
> 
> > 	As you know from recent traffic on the list, there was 
> an agreement 
> > at the Interim Meeting to accept the XCAP docs as working group 
> > drafts.  After that was announced to the working group, 
> Jonathan asked 
> > me to take a look at them to see if there were any gotchas 
> likely on 
> > the use of HTTP, XPATH, and the other components of the proposal.
> > 	It is unfortunate that there is no easier answer here; 
> each has an 
> > engineering trade-off that requires either a shift in the

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 18 Jun 2003 08:47:41 -0700