Re: issue #192 positions

+1

Hervé.

Christopher Ferris wrote:
> 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:40:27 UTC