Re: Updated proposal for issue 192

I like the general direction this is going, but I think we should not call a fault a fault when it isn't one, i.e. when it is not a direct child of the SOAP body.

Detailed comments below.

Jean-Jacques.

Henrik Frystyk Nielsen wrote:

> 0) Use the text already in SOAP 1.2, part 1 [1] for identifying a SOAP fault, that is, a SOAP fault has the local name "Fault" and the namespace URI "http://www.w3.org/2001/12/soap-envelope ".

If a SOAP fault is "to be recognized as carrying SOAP error information" ONLY if it is a "child element of the SOAP body", why not disallow entirely a SOAP fault to "appear within a SOAP header block" (where it's not a fault) ?

> 1) As to the question of determining when a SOAP fault is recognized as an "active" fault in a SOAP message by referring to the text already in SOAP 1.2, part 1 [1]:
>
> "To be recognized as carrying SOAP error information, a SOAP message MUST contain exactly one SOAP Fault as the only child element of the SOAP body. A SOAP fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP body; but, in such cases, the element has no SOAP-defined semantics."

See above.

> 2) Keep the description of a SOAP body in section 2.5 [2] as being "opaque" from a basic SOAP processing perspective. Section 2.5 currently says:
>
> "An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done."

I think we should be adding "except for a SOAP fault", otherwise we contradict ourselves in "5.4 SOAP Fault".

> Then as the next step go on and clarify that as one particular SOAP body "type", we define a SOAP fault which completely describes the semantics and structure of a SOAP fault (see also proposals for point 0) and 1))
>
> 3) Use the proposal listed in [4] for using corresponding HTTP fault codes and SOAP fault codes. Say that a sender MUST use these HTTP status codes in order to comply with the SOAP HTTP binding. A sender that doesn't do this is broken in the same way a sender that includes a DTD is broken. Given the discussion around this issue in particular, I suggest that we add a note or a warning saying that implementers of SOAP receivers are encouraged to detect broken SOAP senders that does not conform to the SOAP HTTP binding.

+1

> 4) Several things have been brought up on this issue: I propose the following "cleanup" of the SOAP representation:
>
>     a) use qualified names
>     b) be consistent in our how names are cased: for example
>
> use "Reason" instead of "faultstring" etc.

+1

Thank you.

Jean-Jacques.

Received on Wednesday, 10 April 2002 05:28:04 UTC