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

Re: MEPS Part II: SOAP

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Fri, 08 Apr 2005 15:20:15 -0400
To: David Orchard <dorchard@bea.com>
Cc: David Hull <dmh@tibco.com>, public-ws-async-tf@w3.org
Message-id: <66b366b7d523341039b213bf5a0c1504@Sun.COM>

On Apr 8, 2005, at 3:08 PM, David Orchard wrote:
>
> 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.
>
To be honest I don't think there's much to choose between them. I think 
we should just go with optional-in, optional-out and be done with it.

Marc.

>
>> -----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.
>>
>>
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
Received on Friday, 8 April 2005 19:20:19 GMT

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