RE: Issue 182: Fault Code restriction: "At Most One Fault Proposal"

Thanks Stuart for writing this up - I realize the amount of work it is.
I think, however, that the text we are discussing has a slightly
different purpose than what you are implying. Section 2.6 "Processing
SOAP messages" talks about how to process *any* SOAP message: you find
the pieces targeted at you, you must do the mU ones, may do the rest,
and then process according to the semantics of these pieces.

The point I was bringing up yesterday is that *if* the rules and
semantics of a block (or the body) are not met then we must guarantee
that the processing does not appear to be successful. The reason why
this has an implication on interoperability is that if I don't know that
a SOAP processor is going to fail in a specific situation, I have no
mechanism for reliably determining the outcome of the processing and
hence can not possibly expect to interoperate.

While the specific fault codes you list below describes specific cases,
they do not cover the general case of the processing model which invokes
the term "understand". It is perfectly valid for a header block or a
body to define states that are not clear fault states, call them warning
states, say, that do not result in a SOAP fault being generated. While
the SOAP processing is indifferent to such states, if the semantics
calls for a fault, we (as the SOAP processor) must guarantee that SOAP
processing is deterministic.

Maybe we can address this doing something like this (including the
paragraph above the one we are discussing as it highly related):

"In all cases where a SOAP header block is processed, the SOAP node must
understand the SOAP block and must do such processing in a manner fully
conformant with the specification for that block. The ultimate recipient
MUST process the SOAP body, in a manner consistent with 2.5 Structure
and Interpretation of SOAP Bodies. If a block or the body cannot be
successfully processed, the SOAP node MUST generate a fault conforming
to the specification for the corresponding block or body being
processed."

The idea of this is that we have symmetry between the MUST process
(going from SOAP to app-defined  specification) and MUST fault (going
from app-defined specification to SOAP).

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>Conclusion
>----------
>The SOAP processing model [3b] is clear about the termination 
>of message
>processing only in the case of mU faults. This is moot for 
>DTDNotSupported
>and versionMismatch faults where processing is unlikely to 
>advance as far as
>processing the content of the envelope.
>
>For sender, receiver and DataEncodingUnknown faults, as far as 
>I can tell,
>the processing model [3b] does not explicitly prohibit some 
>effort being
>made to partially process a message - this is probably an 
>oversight (rather
>than a subtelty) and should be fixed.
>
>In general the circumstances under which each type of fault is 
>generate is
>stated and a MUST,MAY or SHOULD imperative associated with the 
>corresponding
>fault generation. MAY's and SHOULD's are used which leave open 
>the potential
>for a failure to arise that does not generate a fault. Also, there are
>clearly more potential failures possible than are covered in 
>the spec. which
>also leave potential for faults not to be generated (due to omission -
>because full enumeration is not practical).
>
>SOAP also provides for extensions to specify their own fault generation
>behaviour, which also leave open the possibility that 
>extensions also use
>the imperatives MAY and SHOULD in conjuction with the 
>generation of faults.
>
>My conclusion is that the revised proposal, "If processing is 
>unsuccessful,
>at-most one fault MAY be generated by the node." is appropriate on two
>grounds:
>
>a) Some failure conditions permit or advise, but do not mandate 
>   the generation of a fault.
>
>b) It is not clear the the failure to generate an optional 
>   (and even a mandatory) fault lead to interoperability
>   problems that would necessitate a MUST.
>
>Regards
>
>Stuart Williams
>--
>[1]  http://www.w3.org/2000/xp/Group/xmlp-issues.html
>[2]  http://www.ietf.org/rfc/rfc2119.txt
>
>[3]  http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html
>[3a] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#muprocessing
>[3b] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#procsoapmsgs
>[3c] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#reltoxml
>[3d] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#envvermodel
>[3e] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#faultcodes
>
>
>[4]  http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html
>[4a] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#encfaults
>[4b] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#IDAL53U
>[4c] 
>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#rpcfaults

Received on Thursday, 21 February 2002 11:52:58 UTC