issue #192 positions

All,

I took an AI on the 20-Mar telcon to summarize the opposing
positions w/r/t Issue #192[1] "When is a Fault a Fault?" and
to propose a resolution.

Background:

Mark Baker writes in [4]:

But that's not an inconsistency.  Like I said in my example, what if I
wanted a debugging interface on my components such that I could ask
"give me the last fault you sent".  In the tunnelled view of SOAP,
there's no way to know whether what you're getting is the fault
you're asking for, or a fault generated because of your question.

  > I'd hate it if we say "if
  > the protocol binding says the message is/isn't a fault message,
  > this is the true information, otherwise look at the first member
  > of the Body."

Yes, I'd hate that too.  That's why we need a single authoritative
piece of info that processors can use, and why I'm suggesting that for
transport protocol bindings, we can have something in-band, but that
this mechanism SHOULD NOT (would like to use MUST, but I don't think
it's strictly required) be used for application protocol bindings.

Jacek Kopecky writes in[5]:
I maintain that saying "this fault is not fault, it's application
data" should be handled by the application, for example by
wrapping the actual fault in a Body's child element.

Chris Ferris writes in[6]:
I would suggest that we say that a SOAP Fault is a SOAP
envelope containing a SOAP:Fault element as the first child
element information item of the SOAP:Body element information
item, period. That makes it abundantly clear and unambiguous
to a SOAP processor that this is indeed a SOAP Fault message.

If you wanted to support an edge case such as you describe
whereby a Fault element is carried in the Body of a SOAP
envelope (e.g. the gimme the last Fault you issued request)
but is not considered as a SOAP Fault message then
the appropriate means for doing so would be to either a)
wrapper the Fault element in another element that conveys some
harmless intent (like a SOAP RPC req/resp) or b) add a SOAP
extension header with mU="1" that says in effect "IGNORE the
Fault element in the Body of this message, it is informational
and NOT operational".

Stuart Williams writes in[8]:

I think that's a good catch. I think faultHint is only discussed in the
context of the requesting node as well. I think it perhaps also needs
to be used in the transition from Processing to Sending at the
responding node.

The bulk of the material in the HTTP binding was written ahead of the
resolution of Issue 12 (HTTP status codes and faults, loosely described 
as 500 v 200).

======================================================================

Analysis:

It seems clear (to me at least) that SOAP intends that the
semantics of a message that contains a SOAP Fault element
info item as a direct child of the SOAP Body element are that
it is conveying error information generated at some SOAP node.
The SOAP spec does not say anything about the responsibility that
a SOAP node receiving such a message, containing a SOAP Fault,
might have in processing such a message.

The resolution to issue #12[7] was that the HTTP binding would
use the HTTP 500 status response to report a SOAP Fault being
generated at the receiving SOAP node. This resolution was taken
before the TBTF had completed its work on the new HTTP binding
for the Part 2 Adjuncts specification. In general, the new
HTTP binding captures some, but possibly not all of the intent
of the resolution to issue #12. However, this is somewhat
orthogonal to the issue raised in #192 which has a slightly
different slant to it in that it suggests that the HTTP
response code be autoritive and modify the semantics of
the SOAP Fault message which is (I believe) what Jacek and
I are so much opposed to.

It has been suggested repeatedly (see above) that to accomodate a use
case where an application (not SOAP) wanted to exchange
a SOAP Fault element, that it be wrappered in some application-specific
element information item. The problem that exists is that the
SOAP Part 1 specification states quite clearly that the SOAP
Fault element MUST be the first child element information item
of the SOAP Body element information item:

Part 1 Sect 3.4 SOAP Fault[2]

A SOAP Fault is used to carry error information within a SOAP message.

If present, a SOAP Fault MUST appear as a direct child of the SOAP body
and MUST NOT appear more than once within a SOAP Body.

The Fault element information item has:

      * A local name of Fault ;
      * A namespace name of http://www.w3.org/2001/12/soap-envelope;
...

This current wording seems to preclude the usage of the SOAP
Fault element information item in a context where it is
NOT the direct child of the SOAP Body element information item.
Thus, as currently specified, use of a wrappering element
seems to be precluded (although IMO this is unenforcable).

Rather, I believe that the intent of section 3.4 is that
the *semantics* of a SOAP Fault are conveyed by virtue of
its presence as the first child element information item
of the SOAP Body element info item. A *generated* SOAP Fault MUST
be reported in such a way that the SOAP Fault element MUST
be the first child descendant of the SOAP Body element information
item. Any other usage of the SOAP Fault element schema fragment is
unspecified by SOAP. A SOAP node MUST NOT attribute SOAP
Fault semantics to a SOAP message containing a SOAP Fault
element information item in any other context than the
direct child descendant of the SOAP Body element information
item.

======================================================================

Proposal:

Amend Sect 3.4 as follows:
<proposed replacement text>
Part 1 Sect 3.4 SOAP Fault

A SOAP Fault is used to carry error information within a SOAP message.

A SOAP node MUST attribute the semantics of a SOAP Fault message
to all SOAP messages that contain a SOAP Fault element information item
when it is present as a direct child descendant of the SOAP Body element
information item. A SOAP Body element information item MUST
NOT contain more than one SOAP Fault element information item
as a direct child descendant element information item.

Any other usage of the SOAP Fault element schema fragment is
unspecified by SOAP. A SOAP node MUST NOT attribute SOAP
Fault semantics to a SOAP message containing a SOAP Fault
element information item in any other context than the
direct child descendant of the SOAP Body element information
item.

The Fault element information item has:

      * A local name of Fault ;
      * A namespace name of http://www.w3.org/2001/12/soap-envelope;
...
</proposed replacement text>

In addition, in order to ensure that the intent of the
resolution to issue #12 is preserved, the SRR MEP and the
default HTTP binding need to be tidied up.

<current text>
6.1.4 Fault Handling
...

If a SOAP Fault is generated by the Responding SOAP node while it is in 
the Processing state, the generated SOAP Fault replaces the abstraction 
of the Response Message that is used to set the 
"transport:CurrentMessage" property and the state machine transitions to 
the Responding state.
</current text>

<proposed replacement text>
6.1.4 Fault Handling
...

If a SOAP Fault is generated by the Responding SOAP node while it is in 
the Processing state, the generated SOAP Fault replaces the abstraction 
of the Response Message that is used to set the 
"transport:CurrentMessage" property and the state machine transitions to 
the Responding state. In addition, the "transport:FaultHint" property is
set to 'true'.
</proposed replacement text>

The "Instantiation of Message Exchange Context for ..." tables (6.1.3)
need to be updated to include the "transport:FaultHint" property with an
initialized value of 'false'.

7.4.1.2.3 Responding
this set of tables needs to be updated to (somehow) reflect the
processing/treatment of the 'transport:FaultHint' property. In addition,
I think that the "MUST" intent of the resolution to issue #12
needs to be conveyed in this section. Would suggest the following
edit:

s/Set according to the following table/MUST be set according to the 
following table/

Cheers,

Chris
[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x192
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapfault
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0007.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0026.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0027.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0017.html
[7] http://lists.w3.org/Archives/Public/xmlp-comments/2001Oct/0003.html
[8] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0166.html

Received on Friday, 22 March 2002 10:15:48 UTC