XML Protocols Telcon of 5 April 2006

5 Apr 2006


See also: IRC log


BEA Systems, David Orchard (daveo)
IBM, Chris Ferris (cferris)
Nokia, Mike Mahan
Oracle, Anish Karmarkar
Sonic, Glen Daniels
Sun Microsystems, Pete Wenzel
Tibco, David Hull (dhull)
W3C, Yves Lafon
IBM, Noah Mendelsohn
Sun Microsystems, Marc Hadley
Iona Technologies,
Sonoa Systems, Vikas Deolaliker
Ericsson; Nilo Mitra
Oracle, Jeff Mischkinsky
Mike Mahan
Anish Karmarkar


Agenda review

Yves: nothing to discuss from W3C

Mike reviews the agenda. No AOB.

Approval of minutes

Mike: f2f minutes comments from DavidH are not merged yet

March 29 minutes http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0026.htm


Action Items

2006/03/29: Yves

Check the pubrules change to see if the group needs to review the

implied changes to the specs

DONE. See:http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/0000.htm

Yves: nothing to do on the WG side wrt to new pub rules

2006/03/29: Editors of part 3 (Anish, DaveO, ChrisF)

Draft one way text based on the suggestion made in the 29th minutes


Mike: DaveO did that

<dhull> "no state machine" == "simplified" is a theorem, not an axiom

Mike: simplified and non-simplified versions
... anish and chris have you discussed this with DaveO

Chris: not with DaveO but discussed it with each other some time back
... will have some time to look at that

Anish: will have some time to look at that this week

2006/03/29: DavidH

Look through archives of async task force to find earlier drafts of

one-way MEPs


Mike: Like to discuss this more later in the one-way section of the agenda (even though there is no marker for it)

Dave: OK

2006/03/29: Yves

Send email about 202/204 (clarify the way errors like mU are handled

currently using 202)

Yves: did send an email out. got a response from Glen
... wonder if we need a test in the ws-addr test suite

... ongoing discussion with Noah on this

Mike: are u suggesting that we make a formal request for ws-addr WG?

Yves: got a response from paul downing for a test, don't know if that is an official response

anish: paulD is the one looking after the test suite

Yves: we should first finish the discussion on 202 first

<Yves> the issue is to know in the case of RoR if the processing should start or not (ie: mU checking)

anish: i did respond to Yves' email to point out the WSRM usecase http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0011.html

Glen: it is more than MU processing

Chris: what is important has to do with the MEP itself
... when u have a req-res or ror, the MU processing must be done. A 202 means that the message was accepted. Nothing more.
... it would not be appropriate to assume that any RM processing has been done

Glen: but it involves looking into the header to get the sequence id

Chris: it is a matter of specifying that you must do MU processing in case you send an envelope in 202

Glen: it is a little complex
... protocol exists to help two communicating nodes understand what's going on
... ws-addressing allow u to do things like run various MEPs that are different from the transport level
... lot of people assume when they receive 202 that ws-addressing processing has happened
... i wonder if there could be something like ws-addressing 'ack'
... i.e., if there is a problem i'll use the faultTo

Chris: if u do a MU fault, then u are supposed to not do anything and rollback.

davidh: what glen is talking about is Tony's timeline thing.
... if you get a response (202) back, u don't know that the app has processing the message

glen: if i imagine that if i have a channel open (like BEEP) and i know the connection is open, if i get an indication that the ws-addressing has been recoginized, i'll know that the faults will come on that channel

DavidH: if i get 202 response back then it acks like a one-way
... 202 being one way is more appropriate
... I think wsrx tunneling scenario is something else. Not the split case that motivated this
... i looked back at the short soap 1.1 for ws-a. We are non-commital about 202
... we may need implementation experience to resolve this and may want to leave room for that

anish: the way i see things is: 200 req-res, 202 with no envelope nothing can be said, 202 with envelope: MU processing has been done

Chris: 202 response would not be considered the SOAP response
... that is what dave said

<dhull> This SOAP 1.1 request optional response HTTP binding, in conjunction with the SOAP 1.1 binding [SOAP 1.1], can be used for sending request messages with an optional SOAP response. This binding augments the SOAP 1.1 binding by allowing that the HTTP [RFC 2616] response MAY have a 202 status code and the response body MAY be empty. Note that the HTTP [RFC 2616] specification states "the 202...

<dhull> ...response is intentionally non-committal" and so any content in the response body, including a SOAP Envelope, MAY not be an expected SOAP response.

Chris: if you have the seq ack back, that is not the response
... that would be the case, if the reply is not anon. but in case of one-way how would you know
... try to see if you think wsrx is creating another MEP

DaveH: i do have a theory about it: as well as having req-res, you could binding one-way over http-request and one-way over http-respones. Not kosher wrt to http. But would not break anything.
... ws-rx makes good sense if you think of this as two separate one-way flows
... in the ws-rx case, hesitant to say a different MEP
... i wouldn't except the separate bindings of one-way over HTTP request and HTTP response to get very far. would require a lot of buy in

Yves: we say that we are not mandating MU processing
... we should be careful how we phrase
... that

chris: i'm begining to think that it should be status code 200 in case of ws-rx ack
... need to think more about what daveh said
... there are two one-way MEPs sharing the same binding
... almost as the SOAP-response MEP, and we dont say anything about the context

<discussion on how SOAP-res MEP works>

daveh: strange to have a request mep that is one-way and response mep that is one-way.

<cferris> just to be clear, I said that I am reconsidering the 202 v 200 ... not that I have yet come to a conclusion

Anish:: could model this by defining a "SOAP request" MEP analogous to "SOAP response" in such a way that SOAP request response == SOAP request + SOAP response. But then the question becomes what's the difference between the two. Better to just define "one-way" and bind it separately to the halves of a transport-level request-response.

<mikem> thanks daveh for the scribe help

daveo: can look at it as two requests: one is the rx header and the other is the body. So which request is the 200 responding to.

anish: doesn't 200 require the receiver to process the whole message

daveo: rough consensus in the industry is that the main part of the message is soap body and you want to have the soap body to be the "main" request and the http request has to line up with the processing of the body

<dhull> +1 (to the industry :-)

dhull: using 200 other than processing the payload sounds dangerous

glen: as far as http is concerned the app payload is the soap env

dhull: what if there is no soap involved and i send a POST. The server is asked to do two things. One of them will come back in the http response. Both of them could come back in the http response. OR 3xx, where one got done and the other will be done later.

glen: to some extend this is what soap+extension is doing
... at the soap layer it is our responsibility in providing guidance

daveh: it is all the good we can get out of the http spec. we have to make a call.

glen: which is entirely appropriate and can be applicable to http + other things

Mike: another piece of this is: WS-Addr SOAP 1.1 one-way binding. Why wasn't our group involved in doing a review of this

daveh: about soap 1.1

anish: was expecting that the soap 1.1 note would go through LC in parallel with ws-addr wsdl binding

daveh: if we had a significant point to raise, we could raise it

Mike: Sound like the wording is sufficiently vague in the area of the 2xx status code to not preclude conclusions coming from XMLP

... the x-members to WS-A have had opportunty to check this work

....non-xmembers should get a chance too.

chris: i haven't had a chance to look at it

mike: chris, pl. take a look and if you find something please raise it


mike: SC1 would probably go away given the recent discussion on the ML
... lets discuss SC2


mike: it is about whether ror makes any claims whatsoever as to what the response indicates

daveo: chris' response is inline with where the WG is going. My response was about more soapy-ness of the response. Like Chris' better

Mike: Good, so group has now only one counter-proposal to Noah's proposed text; and that is Chris Ferris's.

Mike: SC3 is about outbound message


Mike: we may need Noah here, but lets try again to get a consolidated position

chris: not sure if the state tables would change
... need to make it clear what outbound message is
... would it include information other than soap env
... eg. http response headers

daveo: and response msg isn't quite right

chris: i think we are in agreement, daveo

mike: chris, i think u wanted to drop noah's part b
... i think dave is saying that setting the outbound msg to 'null' does what u want

<more discussion on this and chris agrees with dave>

daveo: u have to say somewhere that there is going to be an evelope or not.
... doesn't allow for an indication that an envelope will or will not follow

chris: retract what i said in the later part of the email. Both (a) and (b) is fine
... I must have read it as 'response' rather than 'respone env'

daveo: it says outbound message and u almost want to say outbound env
... i'm no longer sure that i support noah's proposal

chris: needs to think about this a little bit more

daveo: could almost say leave it as is and undo (b). That is not necessary
... outbound = env + others. 202 with no env will contain a 202 and no env. 200 will say there is an env. How does it know that you are going to put an envelope. How does it know that you are done

chris: problems with streaming too

daveo: leaning towards leaving the text exactly the way it it
... if it is response env, i would agree with noah's wording. But it says 'any other structures'

chris: all we may want to say is that the outbound msg is to be transmitted

daveo: we are almost getting into implementation details
... i support dropping (b) under the assumption that 'structure' include binding specific structures
... i would like to ask Noah what he thinks 'structure' means

<cferris> Start of response available in http://www.w3.org/2003/05/soap/mep/OutboundMessage

Mike: expanding what 'structure' means and dropping (b)

daveo: that could be another approach

chris: remove the word 'envelope'

<scribe> ACTION: chris to respond on the mailing list (and include his new proposal on SC3) [recorded in http://www.w3.org/2006/04/05-xmlprotocol-minutes.html#action01]


Summary of Action Items

[NEW] ACTION: chris to respond on the mailing list (and include his new proposal on SC3) [recorded in http://www.w3.org/2006/04/05-xmlprotocol-minutes.html#action01]
[End of minutes]