<noah2> Links to draft at: http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
<noah2> Mark Baker suggestions: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0057.html
yves updated ed copy errata page and issue list...
<noah2> Chris Ferris comments on response optional draft: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0062.html
<Yves> ACTION: Yves to propose a resolution for rec42 [recorded in http://www.w3.org/2006/03/22-xmlprotocol-minutes.html#action01]
markb made some comments
Noah's first blush review is that they look good
<noah2> "The request has been accepted, and any information that might be
<noah2> present in the response message, possibly including a SOAP envelope,
<noah2> does not represent the results of processing the request message. Any
<noah2> further application processing is beyond the scope of this use of the
<noah2> 6.2 SOAP Request-Response Message Exchange Pattern***."
some discussion about 202 vs 204 and responses?
glen: would be useful to have a
way that a response that didn't do soap processing but had an
envelope.
... get to the rx matrix of processing done/not done...
noah: look at the mep to see if
you will process it..
... look at it as 200 means full processing, 20x may have done some
looking at it but wrt http I didn't do "the" processing.
glen: how about robust in-only binding?
noah: what's wrong with any of
these codes?
... how long does the client wait for potential error?
... typically you build reliable systems from delivering faults.
Message not received, then resend
glen: wsdl says in-only mep,
then uses the "message triggers fault" rule,
... this allows for an application one-way, and return a fault if
one occurs
noah: normal case of robust in-only. You sent me a message no envelope response, can 200 work?
yves: 200 can work, is equivalent to 204
davidh: there's a timeline for processing, at what point do you know that a fault won't come back?
muchos discussianos sobre las intermediarios
Discussion focuses on what does the sender know..
davidH: how about a table/list/ showing various scenarios?
<Yves> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0009.html
<Yves> + clarification that error backchannel is there for mU-like errors
<noah2> The 202 response is intentionally non-committal. Its purpose is to
<noah2> allow a server to accept a request for some other process (perhaps a
<noah2> batch-oriented process that is only run once per day) without
<noah2> requiring that the user agent's connection to the server persist
<noah2> until the process is completed. The entity returned with this
<noah2> response SHOULD include an indication of the request's current status
<noah2> and either a pointer to a status monitor or some estimate of when the
<noah2> user can expect the request to be fulfilled.
<noah2> The request has been accepted for processing, but the processing has
<noah2> not been completed. The request might or might not eventually be
<noah2> acted upon, as it might be disallowed when processing actually takes
<noah2> place. There is no facility for re-sending a status code from an
<noah2> asynchronous operation such as this.
questions around when can an intermediary decide to return 202 versus wait for next hop response..
noah: question about timeouts on tcp under http
glen: so what is known under
successful response?
... example, 204 under soap context.
... is everything done?
<noah2> 10.2.5 204 No Content
<noah2> The server has fulfilled the request but does not need to return an
<noah2> entity-body, and might want to return updated metainformation. The
<noah2> response MAY include new or updated metainformation in the form of
<noah2> entity-headers, which if present SHOULD be associated with the
<noah2> requested variant.
yves: mU check has been done, no errors from that. that's it.
daveO: what if fault doing ws-a processing, can 204 be returned there?
glen: hits the brilliant point of when does the ws-a "know" to release http connection..
davidh: In mep state machine, it says if in the receiving state and fault generated, then make fault available.
glen: maybe ws-a is saying because I'm using WS-A, do another layer of processing,
noah: the definition of one header may affect the normal behaviour of other headers
davido: this could be that the
WS-A spec says stay in the receiving state until it decides that it
has done ws-a processing
... the question is how does the WS-A spec say time to move to the
next state
davidh: there's a state machine lurking..
yves, I agree this is a ws-a issue. But ws-a could be writing in terms of that state machine and what the state machine is
<Yves> or we can define in terms of channels (when the spec takes control of the channel, if present)
I spaced out on scribing...
<noah2> What I said was that I think we should not in our spec encourage misuse of HTTP
<noah2> In particular, maybe we can say that when an envelope comes back with 202, that we say nothing about its semantics, and don't specifically call for SOAP processing on it.
<noah2> Note that higher level specs, such as RM, may request that SOAP processing be done after all, but such processing is beyond the scope of this MEP.
<noah2> Indeed, such specs SHOULD indicate where consequent faults should be delivered, etc.
<noah2> "This binding of SOAP to HTTP is intended to make appropriate use of HTTP as an application protocol."
davido: when sending a soap
envelope, there may be many "requests" in it specifically multiple
headers.
... if there are 6 requests in the message, what does 202
mean?
noah: doesn't say much about any
of them.
... 200 is about all 6 requests, and that's the net
response.
<Yves> http://www.ietf.org/rfc/rfc3205.txt (re: tunneling on HTTP)
<Yves> it basically says "if you are tunneling, use 200 and 500 exclusively"
davido: can look at rx + body as 2 requests, then if rx allows 202 for ack it's actually splitting the response across 2 status codes.
noah: is this tunnelling?
... probably should have said that rx folks should have written a
binding for http that says they are tunneling
[NEW]
ACTION: Yves to propose a resolution for rec42
[recorded in http://www.w3.org/2006/03/22-xmlprotocol-minutes.html#action01]
[End of minutes]