W3C

XML Protocol Telecon

22 Mar 2006

Agenda

See also: IRC log

Attendees

Present
BEA Systems, David Orchard
IBM, Noah Mendelsohn
Nokia, Mike Mahan
Sonic, Glen Daniels
Sun Microsystems, Marc Hadley
Sun Microsystems, Pete Wenzel
Tibco, David Hull
W3C, Yves Lafon
Regrets
IBM, Chris Ferris (phone)
Oracle, Anish Karmarkar
Absent
Iona Technologies,
SAP AG, Volker Wiechers
Sonoa Systems, Vikas Deolaliker
Excused
Oracle, Jeff Mischkinsky
Chair
Mike Mahan
Scribe
David Orchard

2. Agenda review, scheduling and AOB
- Announcements W3C?
- AOB?

3. Approval of minutes:

04 Mar: preliminary minutes at:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0006.htm
lPENDING

15 Mar:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0010.htm
Approvedl

4. Action Items: http://www.w3.org/2000/xp/Group/Admin/#pending

2006/03/04: Anish
Start email discussion on what FAF really means.
PENDING

2006/03/04: Noah
Suggest how the group should proceed in reviewing draft
PENDING (we can do this in this telecon, in next agenda item)

<noah2> Start with this note if you want to see response envelope optional: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html

<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

Summary of Action Items

[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]


Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/07/26 20:59:30 $