RE: Minutes of 2005-04-06 call

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.

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.

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.

Cheers,
Dave



> -----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.
>

Received on Wednesday, 13 April 2005 22:12:15 UTC