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