Re: Issues 12 & 192

Mark Baker writes:

>> My proposal just *suggests* that it be a feature of 
>> all application protocol bindings that the fault 
>> mechanism of the underlying protocol be authoritative 
>> in determining whether a SOAP fault be processed as a
>> fault or not.

I think we need to be very clear on the relative responsibilities of the 
binding vs. the soap node that it is supporting. 

* The responsibility of the binding is to deliver the Infoset [1].  That's 
true whether the Infoset contains a fault or another envelope, and it's 
true independent of whether the underlying protocol has its own notion of 
error or status.

* Chapter 2.6 of framework [2] specifies the logic used by a SOAP node to 
determine the processing of an envelope that has been received.  Unless I 
am missing something, these rules apply equally to envelopes containing 
faults.

* Bindings may signal to the local node failure to transmit or receive a 
message.  The reasons for such failure and the means used to determine 
whether such failures have occurred are binding specific.  An obvious 
example might be loss of hardware connectivity, but we cannot prevent a 
binding from signaling such failure based on the presence or absence of 
status codes from the underlying protocol.   These signaled errors not the 
same architectural construct as a SOAP fault; they are manifest as 
transitions in the state machine for the binding.

* If the application protocol (e.g. HTTP) has a standard means of 
signaling that the message being transmitted represents failure at the 
application level, a binding to that protocol MAY (and in many cases 
SHOULD) adopt such signal when transmitting a SOAP  fault message.  That's 
why we use HTTP 4XX and 5XX for SOAP faults.

The second point above makes clear that no binding can make a 
determination as to how a SOAP envelope is to be interpreted; the binding 
can signal failure to receive the message, but (in the absence of 
features) cannot change its interpretation.  Therefore, it would be 
possible for an HTTP binding receiving a 4XX or 5XX to claim to the SOAP 
node that in fact no message had been received.  If the message is 
delivered, the SOAP node will use QNames in the envelope to determine 
whether a fault has occurred, and if so why.  The binding can, if it 
wishes, assure that it redundantly encodes sufficient information that it 
knows unambiguously from checking its own status codes that the envelope 
does indeed contain a SOAP fault.  Still, it is the envelope that is the 
fundamental carrier of their information, and chapter 2 of the framework 
document that specifies the logic for determining how the node processes 
the fault.

In short, I disagree strongly with the suggestion that any binding would 
be the principal determinant of whether a message carried a SOAP fault.  I 
do think that a well constructed binding can ensure that there is never 
disagreement between what's in the envelope and signals encoded in the 
underlying protocol.  In such cases, the binding-specific signal may be 
taken as a highly reliable hint.

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#bindfw
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#procsoapmsgs

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 26 March 2002 21:37:06 UTC