RE: MEPS Part II: SOAP

Marc,

Let's assume that a 4/5xx indicates a possible SOAP fault then.  The sender may generate something to put in a body or not, the receiver won't know what it is until it gets it.  I don't think there's any way that we could write up which error codes will or won't have a body, so we just have to live with it.  

The receiver of a 4/5xx has to wait to find out whether there is a body or not.  C'est la vie.  If they got a SOAP fault, they can pass it up.  If it's not a SOAP fault, then there may be some other way of passing an error back up, but it's not in the SOAP MEP.   

My point was that in-optional-fault is better than in-optional-out, which you haven't responded to.  We've clarified expectations on in-optional-fault, but I can't tell which mep proposal you support.

Dave

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM]
> Sent: Friday, April 08, 2005 11:53 AM
> To: David Orchard
> Cc: David Hull; public-ws-async-tf@w3.org
> Subject: Re: MEPS Part II: SOAP
> 
> On Apr 8, 2005, at 2:11 PM, David Orchard wrote:
> 
> > I think this is good work, where you are going.  It certain is similar
> > to the work that I published.  There are some unanswered questions
> > though.
> >
> > 1. Should there be an in-optional-out or in-optional-fault or both
> > soap meps?  I'm leaning towards in-optional-fault because I think that
> > the SOAP MEP layer needs to be self-describing wrt responses, and I
> > don't see any value in an in-optional-out where the out could be not a
> > fault.  The logic for HTTP:
> >
> > - One-way: http response codes ignored, sender/receiver know that
> > response body can't be generated.
> >
> > - Request-response: http response codes relevant: 2xx indicates a SOAP
> > BODY response, 4/5xx indicates SOAP FAULT response, 404 indicates no
> > SOAP BODY or FAULT response.  Senders and receivers know whether to
> > wait or not depending on the status code.
> >
> > - In-optional-fault: http response codes relevant, FAULT only in 4/5xx
> > (excluding 404).  Sender and receiver know exactly what can be sent.
> >
> I don't buy that 4/5xx indicates a SOAP Fault response. It *may*
> indicate that but it might equally indicate that something went wrong
> in my HTTP infrastructure *before* any SOAP processing occurred and the
> entity body could include some HTML error message.
>

Received on Friday, 8 April 2005 19:08:33 UTC