See also: IRC log
Yves: nothing to discuss from W3C
Mike reviews the agenda. No AOB.
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
approved
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
Done
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
Done
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
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0051.html
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
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0050.html
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]
Adjourned
[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]