W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > April 2005

RE: MEPS Part II: SOAP

From: David Orchard <dorchard@bea.com>
Date: Fri, 8 Apr 2005 12:08:27 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0ECCEF9D@ussjex01.amer.bea.com>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>, "David Orchard" <dorchard@bea.com>
Cc: "David Hull" <dmh@tibco.com>, <public-ws-async-tf@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 8 April 2005 19:08:34 GMT