Re: Issue 192; HTTP binding looks ok

 Mark,
 I think the current text may be interpreted as the message being
authoritative, the binding mandating use of 4xx and 5xx for SOAP
Faults and the transition table expecting the two sources of
"faultness" of the message to be in accord.
 I think that if we decide that ultimately the message is the
authoritative source here, we'll just have to add a text saying 
that if there is a discord (fault message on 2xx, non-fault on 
4xx, 5xx) it's the same kind of error like receiving an 
incomplete envelope - transport error.
 Or if we decide that the faultHint is in fact a faultOverride, 
we'll have to clarify that.
 I understand that taking the HTTP status code as the
authoritative source of this information is very REST but as I
still favor the tunneling approach and I haven't seen any clear
indication from the group that our HTTP binding will be REST, we
probably want to get to a compromise.
 Using the HTTP error status codes for SOAP faults is not
completely against the tunneling approach, but making the status
codes override the message is crossing the line, at least for me.
 Maybe the group should decide which approach to take in our
binding and accept it fully, or make two HTTP bindings.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

P.S: Mark, I really want to talk to you about REST and SOAP, how 
about at the WS-Arch and WS-Desc f2f? 8-)


On Mon, 18 Mar 2002, Mark Baker wrote:

 > Issue 192[1] is the recently created issue about when should a fault be
 > processed as a fault.
 > 
 > I just had another look at the default HTTP binding, and noticed that
 > the state transitions in 7.4.1.1.2 that are triggered from a HTTP
 > status line request, are actually in synch with my view of a how a
 > fault should be recognized (assuming faultHint is authoritative).  So I
 > think the part of my proposed resolution regarding needing to fix the
 > HTTP binding, is unnecessary at this time.
 > 
 > MB
 >

Received on Monday, 18 March 2002 18:18:39 UTC