Re: issue #192 positions

Mark,

Comments/responses below.

Cheers,

Chris

Mark Baker wrote:

 > Thanks for doing this Chris.  I think you've got all the required
 > context in one message, well done.
 >
 >
 >>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.
 >>
 >
 > That's not clear to me.  If I had seen anything in the spec saying so,
 > I would have spoken up long ago.


Well, what the spec says now (quoted in the write-up) is that
the SOAP fault MUST only appear as a direct child of the SOAP Body
and that it MUST only appear once. I inferred the semantic intent.


 >
 >
 >>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.
 >>
 >
 > Erm, I thought it was for any of the fault codes specified in that
 > table?  Anyhow, not a big deal right now.


Yes, I could have been more thorough. I meant the whole range
of HTTP responses cited in the resolution text (which I wrote!:)


 >
 >
 >> 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.
 >>
 >
 > Agreed.
 >
 >
 >>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.
 >>
 >
 > Currently, the specification says nothing about what it means for a SOAP
 > fault to be sent over a 200 response.  Issue 12 doesn't talk about that
 > case, nor does the state transition table deal with it.

It says nothing because a SOAP Fault is supposed to be
sent with a non 2xx status response in the HTTP binding.


 >
 >
 >>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.
 >>
 >
 > Again, had I seen anything in the spec that said this, I would have
 > brought it up.
 >
 >
 >>Any other usage of the SOAP Fault element schema fragment is
 >>unspecified by SOAP.
 >>
 >
 > Now *that*, I agree with. 8-)

Okay, but the spec says effectively that you can't use it
that way (currently) by saying that it MUST be present
as a direct child of the SOAP Body element info item.

 >
 >
 >>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.
 >>
 >
 > Well, didn't you just say that the behaviour was unspecified?  Is this
 > paragraph just your opinion, or are you drawing a conclusion from some
 > text in the spec?  The text above doesn't suggest it, from what I can
 > determine.

Yes, I said it was unspecified. What I say above closes
the loop by stating unambiguously that a SOAP node MUST NOT
attribute SOAP Fault semantics when the SOAP Fault element
info item is NOT a direct child of the SOAP Body element.

 >
 >
 >>======================================================================
 >>
 >>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>
 >>
 >
 > I thought this was supposed to be compromise? 8-)  It's worse than the
 > status quo! 8-O
 >
 > I cannot accept that resolution, because it says that a fault sent on
 > a 200 response must be treated as a fault.
 >
 >
 >>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/
 >>
 >
 > Agreed.
 >
 > Also, 7.4.1.2.2 needs to be updated to add faultHint=true on the 4xx
 > responses.
 >
 > MB
 >

Received on Monday, 25 March 2002 08:16:29 UTC