RE: issue #192 positions

I am definitely in the Chris & Jacek camp -- the SOAP:Fault MUST be
authoritative, and the carrying protocol hints are just those.

I look at this as a layering issue.  SOAP is the protocol we're dealing
with.  It has to have some rules.  A carrying protocol (carrying ==
looser version of transport as I didn't wanna go there) has rules as
well. But it doesn't make sense that the inner protocol makes
requirements on the outer protocol.  SOAP must be able to categorically
state what's a fault and what's not.

Consider the following somewhat tangential but relevant case.  Some
service handles requests via both, say, JMS and HTTP.  If the 5xx/2xx
response overrides the message content, then the same message, arriving
on different "media", has different results.  This seems bad.  And, to
me, seems like a sufficiently convincing argument against.


Also, are there issues (I don't know) regarding 500 meaning "something
happened in the immediately downstream connection" to Http?  If the 500
is the authoritative answer, any other participant in the message stream
would have to "forward" (although it's backwards...) the 500 to continue
to propogate the fault.  Again, that seems confusing.


There are probably cases where the binding might need to infer
information from the reciept of a 5xx.  For example, a 5xx with no
content (or no valid SOAP message (service not available, etc.)) might
be turned into some SOAP fault by the binding.  But, again, the 500 was
interesting, in that case, only where the SOAP message was not valid --
which seems OK.


Bottom line:  SOAP should be able to determine its fate on its own.  If
it is a valid SOAP message, than its answer should be authoritative.
Hints are OK, but they are hints.  SOAP should, in this case, "control
its own destiny."

/fred

--
Fred Carter -- Edgility Software, Inc.
mailto:fred.carter@edgility.com
phoneto:+1 (510) 433.6525


> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Christopher Ferris
> Sent: Friday, March 22, 2002 7:15 AM
> To: xml-dist-app@w3.org
> Subject: 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#soap
fault
[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 13:54:52 UTC