Subject: [Simple] Thoughts on XCAP

From: [email-masked]
Date: Fri, 13 Jun 2003 16:45:08 -0700

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

---

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,

---

From: [email-masked]
Date: Thu, 19 Jun 2003 12:04:34 +0300

Lisa,

My comment about availability of WebDav to clients was not restricted to PCs and work stations.

In any case, my email was mainly questioning the severity of the problem at hand and the real need to use something like WebDav to solve it. There are certainly simpler ways to solve this problem, if we see the need. One of them is what I listed as option 2 in my earlier posting.

Regards,
Hisham

> From: ext Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2003 6:48 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: [Simple] Thoughts on XCAP
> 
> 
> 
> > 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?
> 
> 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.
> 
> > 
> > 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: [email-masked]
Date: Thu, 19 Jun 2003 12:04:34 +0300

Lisa,

Regards,
Hisham