W3C XML Protocol Working Group teleconference, 22 May 2002

1. Roll

Present 31/26 Excused Regrets Absent

2. Agenda review and AOB

No items.


3. Approval of May 15 telcon minutes

No changes requested.  Approved as posted.


4. Review Action Items


5. Status reports

-- Primer
Nilo: Last draft from 17 May.  Some updates made.  Sent a note to WG group
explaining.  No further work until comments submitted (comments due 24
May).  Ready to go to LC.

-- Spec
Henrik:  Two things pending on the to do list:  202 / 204 related and some
comments received from Chis and Noah that have not all been incorporated.

-- Conformance
Anish / Lynne:  Status covered under pending action discussion (agenda item
Henrik:  We should stop calling it conformance document and call it a test
suite or test collection.  There is text in the specification intro stating
that being conformant to test suite doesn't imply spec conformance and vice
General agreement to use test collection.
DavidF:  Run through doc that goes out on 24 May changing appropriately and
verifying that the term 'conformance' is used properly where it appears.

-- Usage scenarios
John:   Nothing to report.  Ready to go to LC.

-- Requirements
BobL:  Nothing to report.  Ready to go to LC.

-- Email binding
Highland:  Latest rev posted (16 May).
DavidF:  Deadline for comments is 24 May.

-- Media type
MarcB:  Except for revised SOAP action (moving into action attribute), it's
ready to go.  Will do those changes in time for the next WG telcon.


6. Loose ends



7. TAG decision on HTTP Binding

DavidF:  TAG made a finding to us [1] that current version of SOAP 1.2 has
contravened basic rule of web architecture:  that all important resources
on Web should be identified by URIs.  We do not provide a GET method in our
HTTP binding.  The GET method is important because it allows an HTTP
resource to be identified by a URI and it is the way of accessing resources
in a 'safe' manner.  Current spec only supports POST.  GET would provide
the same access and provide a URI reference to that resource.  In sum, we
need to add support for GET (in addition to POST) and perhaps provide
guidance on when each is used
Noah:  There is an additional aspect.  Part of the issue is balancing
between GET and POST.  One aspect of GetStockQuote either way is that the
ID of the stock is inside the body and not in the URI.  Depending on where
we go with the resolution, there may be questions not only regarding GET
and POST but also PUT.
DF:  We need to figure out when we're going to do this and decide an
outline of what we're going to do.  We need to provide support for GET
(which may branch out into PUT), guidance in usage of one or the other,
Paul:  TAG thinks we should do Option 1 as defined in agenda [2].  Can be
solved during LC with a mechanism based on what David Orchard proposed.
TAG doesn't want to slow down LC or SOAP 1.2.
Chris:  There are some who don't like this approach.
DF:  The various options are:
Option 0 - What Paul is really outlining.  It assumes a solution already
exists a la David Orchard's proposal and we just point to that and continue
on with planned LC schedule
Option 1 - Does not assume a solution exists.  During LC period we would
work on a solution
Option 2 and 2 prime - Do not assume a solution exists.  These options are
ways of saying we do some parts of the solution now and finish them during
LC.    Cons associated with Options 1, 2 and 2 prime are that we need to
show implementation experience for the GET method in the HTTP binding and
we risk being sent back to second LC by not obtaining that implementation
Option 3 - Do all this work up front before we go to LC.  If an agreed
solution really exists then 3 is really short.  If not, it will take an
extra amount of time to use this option.  Plus side - we provide more time
to implementers to provide implementations that would allow us to have a
single LC.
Noah:  DavidO's work is a nice contribution, but deficient.  It does not
deal with all the 'interesting' use cases. Specifically, if we have a
resource out there we have to use it consistently.  We need to lay out a
set of goals, success criteria, and use cases that we could use to
recognize an appropriate solution and stack all the various proposals up.
Our spec says a lot of things about how you write a binding, relate it to
the framework, use MEPs.  DavidO's proposal is not in that form.  When we
try to put it in that form we will probably uncover a number of issues.
Option 0 is a bit too simplistic.  W3C process effectively pushes us into
Option 3.
Henrik:  In the POST we have in SOAP for the HTTP binding, we make a set of
choices.  The interaction is req/ res, short term, and includes other
associated restraints.  Is there any way to say one of the constraints on
binding is that it is not safe?
DavidF:  To summarize, in the SOAP HTTP binding we could clarify that POST
is for non-idempotent operations and there exists in HTTP other methods
suitable for safe operations.  Users are free to go off and use those.
Henrik:  Yes. And we get rid of the GetStockQuote example.  We already have
a set of constraints, why couldn't this be one of them?  The same could be
said for DELETE.
PaulC:  I don't think you're going to fool the TAG.  You can remove it from
the spec, but we'll still get commentary that there is a simplistic RPC
Henrik:  Use GET request without SOAP interaction at all, and make it a
SOAP message in the response.  The gives us full cover in how to deal with
a URI and makes it referencable.
Marc B: Agree completely with Henrik.  Hope TAG doesn't see it as trying to
fool them.  We should take responsibility for the spec, not how people are
mis-using it.
Jacek:  Don't like the idea of transport binding that would restrict the
set of messages we can carry through it.  It seems weird if we say only
certain kinds of messages could go through our HTTP binding and we don't
provide bindings for the rest of the messages.    We should support all
possible messages we want to send to SOAP if we provide a transport
binding, and we should do PUT and DELETE.  Option 3 and 1 are preferable,
in that order.
Chris:  Agree with Henrik.  Also agree with Noah.  There are a number of
possible ways to approach Option 3.  The key thing is how far we really
want to take this.  We could take Option 3 to a point where we don't get to
LC until September - not sure that would be such a good thing.  Some
sympathy about splitting things up, but largely nothing that we do in the
binding other than the binding framework would really be impacted.  Favor
Option 2 or 2 prime .  Signal where we're going and maybe start it so
people have a clear understanding - a hybrid of what Henrik and Noah are
suggesting. I don't favor the approach outlined by DavidO.
Highland: +1 to Chris's comments.  Also, the title the TAG used "SOAP HTTP
binding GET method (?)", is misleading and may confuse the audience.
Naming it a binding when it just addresses a particular feature or property
isn't correct.
Noah:  Don't need to make it unduly complicated.  We have heard a number of
different perspectives.  But if we don't say anything more than what Henrik
is proposing, it's not SOAP.  (processing model, binding framework and
MEPs). Will need a new one-way pull MEP (binding requests pull and back
comes message, fault handling, etc.) and possibly one for POST.  Other
things as well to do a proper job with Henrik's proposal. Such work would
require several weeks, and it should be described as part of the binding.
Henrik:  Agree.  Have to explain a bit more about what this is.  We should
write up a "proposal for the proposal" describing an outline of what it is
we're going to try and do, send it out to the TAG and whoever else may have
an opinion for feedback so we don't burn cycles on it and then figure out
people don't like it.
DavidF:  Investigate writing a "proposal for a proposal".  Run it by the
TAG and then if acceptable go to LC and complete the proposal work during
Noah:  If we ignore the interim step of checking with TAG, when would we
have final text for all this?  Guessing 3-5 weeks to get to LC quality for
the final text to incorporate into the spec.   Can we take the risk of
trying to go to LC, how big is this and how long do we wait?
Henrik:  We can make a statement that this is the last issue we're dealing
with, that this doesn't open it up to other issues.
DavidF:  No intent to reopen the issue list.  Simply to deal with this
issue that has come down from the TAG.
Henrik:  If we use the "proposal for the proposal" (2 stage), will have to
circulate to TAG and other places, which will take some time for review.
DavidF:  Talked with a couple of other TAG members. I note the second
sentence in the TAG resolution text "TAG appreciates urgency in SOAP 1.2
specs....".  At least one TAG member said that means they are willing to
give WG some of their time to help work on this.  Given TAG has make
statements of their appreciation of the urgency and even offered their
help, we can expect quick turn around from TAG.
DavidF: We need to make a decision. Here are the options outlined so far:
(a) Choose option on 'when' question now, i.e. choose one of the three
options outlined in the agenda.
(b) Spend time now (20 minutes or so) trying to narrow solution space and
then make a decision.
(c) Initiate a small group to go off and meet in a short time (end of week)
and come up with proposal.  Next telcon decide whether to go forward with
it.  Delay our current schedule by at least a week.  Spend some solution
deciding what solution looks like so we can make a better-informed choice.
Straw poll on (a),(b),(c).  Majority of respondents favored (b).
Henrik:  The approach being discussed would also solve problem of 202 and
DavidF:  And presumably there would be an association between this one-way
MEP and the description of how to use GET.
Noah:  Yes.  One way pull consists of a request for a SOAP message,
transmitted in a binding specific manner, answered by a SOAP message from
the responder to the requestor.  Different from an RPC (method name and
list of arguments) - this is just saying I know a URI, would you please
pull a representation of it as a SOAP message.  Can you get symmetry
between the GET and the UPDATE case?  Not done with RPC until we have that
sorted out.
DavidF: We seem to have identified a one-way pull MEP, and a GET
description; what else required?
Henrik:  Can send a SOAP message in a request, which might be the POST and
get a GET back.
Noah:  That's a different MEP
Noah:  Top priority is to get the RPC model right, needs to be in scope of
what we sign up to do.  Maybe PUT as well as POST.
DavidF:  What are the pieces we're agreeing to?
Jacek:  Would the one way pull MEP make TAG happy?
Noah:  Strong suspicion is that we need to tell a little bit of the story
of RPC.
DavidF:  There is a thread in the TAG that some education is needed.  To
summarize, the approach we're discussing includes:
(1) Description of one way MEP
(2) Integration of that MEP into the HTTP binding using GET
(3) Clean up the RPC story about when and how to use SOAP messages and URIs
(4) How do you return a URI for a created resource (convention for setting
content location).
Noah:  Do the first 3 - somewhere in the process prepare a version for
quick review for TAG and then determine if we do part 4.
DavidF: OK, so the proposal is to do the three parts (1-3 above), we do
this piece of work before we request LC, and we put it into our spec as
part of the LC documentation with assumption we delay LC by around 1 month.
[No dissent from the WG on this proposal.]
Henrik:  It would be nice to know that this solution is 'it'.  How can we
communicate this  to TAG so we don't delay a month and find out it is not
an approach they will approve?
DavidF: We assume the approach is likely to fly with the TAG. Note that
they gave us a huge leeway on how we resolve this.
Noah:  The only way we could blow this is to go to them so early in the
process that they don't understand how much of the problem we intend to
DavidF:  Let's form a task force charged to flesh out these three points
which we will review at the next WG telcon.  At that point, we'll decide if
it's in a state to go to TAG.  We will postpone LC until we have
implemented this solution in our specification.  Task force call scheduled
for Thursday 22 May at 11:00 EDT / 8:00 PDT for 120 minutes.


8. Comments against spec

DavidF:  take to email to try and resolve there.


9. HTTP codes 202 and 204

Discussion on 202 and 204 likely superceded by TAG GET issue resolution so
we need not worry about it right now.

[1] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002May/0132.html
[2] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002May/0133.html