Re: Minutes of 2005-04-06 call

On Apr 13, 2005, at 6:08 PM, David Orchard wrote:

> Fact: A SOAP FAULT is NOT allowed to flow on the HTTP Response in the
> SOAP HTTP Binding when the HTTP status code is 2xx, per the SOAP HTTP
> Binding.
>
> Fact: Any new SOAP MEPs bound to HTTP must specify the allowable HTTP
> status codes for SOAP Faults.
>
I'd put this another way: the SOAP HTTP binding may need adjustment to 
accommodate new SOAP MEPs.

> Assertion: The SOAP HTTP Binding behaviour should hold true for any new
> bindings or MEPs, that is SOAP FAULTs cannot come with an HTTP 2xx.
>
> Fact: WSDL in-only MEP does not allow SOAP Faults to be reported to the
> application.
>
> Fact: WSDL robust in-only MEP does allow SOAP Faults to be reported to
> the application.
>
> Fact: faults that are not SOAP Faults may be reported in a variety of
> mechanisms that are unspecified in SOAP.
>
> Assertion: I wish to specify SOAP MEPs supporting SOAP Faults.
>
> Assertion: I do not care to specify SOAP MEPs for non-SOAP Faults, nor
> do I wish to talk about this for a millisecond longer.
>
Splendid, seems we're all in agreement on this aspect of the discussion 
at least.

> Assertion: I believe there is a direct and mandatory relationship
> between SOAP Faults, new SOAP MEP(s) to transmit those SOAP Faults, the
> HTTP Status codes for the SOAP Faults, and WSDL MEPs.
>
> Proposal: As I proposed earlier, a SOAP in-optional-Fault MEP that is
> bound to HTTP permits a SOAP Fault to be transmitted with some HTTP
> Status codes of 4/5xx.  I believe this is superior to in-optional-out
> SOAP MEP because it eliminates the uncertainty of whether a response 
> can
> be sent with an HTTP 2xx status code.  In my proposed MEP, an HTTP 2xx
> means no SOAP response coming back, HTTP 4/5xx means possible SOAP
> Fault.  This is an obvious SOAP MEP to default for WSDL robust in-only.
>
This is where I get lost. What aspect of the elimination of the 
optional response is superior ? WS-I already defines the use of the 202 
status code when using HTTP for SOAP 1.1 one way and if the SOAP 1.2 
HTTP binding is clarified to do the same then you get the same 
unambiguous response for in-optional-out as you could for 
in-optional-fault. Either way we need to fix the SOAP 1.2 HTTP binding 
to allow an empty HTTP response which isn't currently accommodated.

Marc.

>
>> -----Original Message-----
>> From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-
>> request@w3.org] On Behalf Of Marc Hadley
>> Sent: Wednesday, April 13, 2005 1:52 PM
>> To: Anish Karmarkar
>> Cc: public-ws-async-tf@w3.org
>> Subject: Re: Minutes of 2005-04-06 call
>>
>>
>> +1, the discussion of in-optional-fault to cope with HTTP errors has
> me
>> completely baffled.
>>
>> Marc.
>>
>> On Apr 13, 2005, at 2:23 PM, Anish Karmarkar wrote:
>>
>>>
>>> Apologies for missing the last concall.
>>>
>>> Perhaps I'm missing something here, but I don't understand why
>>> transport level problems/faults (such as HTTP 404 status code) are
>>> being discussed in the context of MEPs. The way I see it, there are
>>> lot of things that can go wrong, even in the case of one-way MEP
> using
>>> UDP. For example, there may be a DNS problem or a network disconnect
>>> (for that matter non-transport related problems such as
> out-of-memory
>>> errors can also occur). To me, this does not affect the MEP design
> in
>>> any way. The application may have to deal with it as it may see that
>>> error somehow/somewhere, but this does not change the MEP (from an
>>> in-only to robust-in-only). In the case of SOAP the change from
>>> in-only to robust-in-only has to be made iff there may be a
> SOAP-fault
>>> coming back.
>>>
>>> -Anish
>>> --
>>>
>>>
>>> Hugo Haas wrote:
>>>> ... are at:
>>>>     http://www.w3.org/2005/04/06-ws-async-minutes.html
>>>
>>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> Business Alliances, CTO Office, Sun Microsystems.
>>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Thursday, 14 April 2005 13:36:24 UTC