RE: Issue 182: Fault Code restriction: "At Most One Fault Proposa l"

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 21 February 2002 19:55
> 
> Chris,
> 
> >I read Stuart's email, and I just don't see that he's 
> >suggesting that a node might silently fail w/r/t the SOAP 
> >processing model.
> 
> The place I am pointing to in Stuart's mail is towards the 
> end where it says
> 
> >My conclusion is that the revised proposal, "If processing is
unsuccessful,
> >at-most one fault MAY be generated by the node." is appropriate on two
> >grounds:
> >
> >a) Some failure conditions permit or advise, but do not mandate
> >  the generation of a fault.
> >
> >b) It is not clear the the failure to generate an optional
> >  (and even a mandatory) fault lead to interoperability
> >  problems that would necessitate a MUST.
> 
> Maybe I am misreading this but a) seems to indicate that it should be
> possible to have some fault case as part of processing a SOAP message
> that doesn't call for generating a fault. The reason why this makes me
> nervous is that we as stated in my earlier mail describe in section 2
> what it means to understand and this is the particular context in which
> this text is to be read.

This processing word may be biting us. We have an enumerated list of things
that we do to a message in part 1 section "2.6 Processing SOAP Messages".
Upto the end item 3 the blocks in the message are inspected, but not
processed. At item 4 some blocks in the message may be processed (in strict
accordance with the rules...).

The point is that the core of the section 2.6 speaks in terms of processing
the *blocks* in a message, and whole section is about processing a SOAP
message. When we speak of message processing being unsucessful there the
failure may arise:

	outside the rules of section 2.6 (eg.
DTDNotSupported,VersionMismatch)

	in the outer part of section 2.6 (eg. MustUnderstand)

	in processing blocks targetted at the node (eg. Sender, Receiver,
DataEncodingError)

The phrase "If processing is unsuccessful..." is a little imprecise and this
may be what's giving us a problem.

> Rather than bringing in question whether to generate a fault or not, I
> propose that we say who is responsible for defining the fault states. In
> the SOAP 1.2 itself, we define some fault states covering specific
> situations (e.g. DTDNotAllowed). For header blocks and body contents it
> is up to the people defining the semantics for SOAP blocks and body
> contents to define fault states (e.g. credit card number not valid).
> This is the purpose of the proposed formulation (repeated here for
> convenience):
> 
> "In all cases where a SOAP header block is processed, the SOAP node must
> understand the SOAP block and must do such processing in a manner fully
> conformant with the specification for that block. The ultimate recipient
> MUST process the SOAP body, in a manner consistent with 2.5 Structure
> and Interpretation of SOAP Bodies. If a block or the body cannot be
> successfully processed, the SOAP node MUST generate a fault conforming
> to the specification for the corresponding block or body being
> processed."

So are we defining successful processing to be the absense of a generated
fault, unsuccessful processing to be the generation of a fault?

ie. two concepts or one (processing outcome (success/failure) and fault
generation).

Currently I think our language implies two concepts and a processing failure
may result in the generation of a single fault.

I think you are (at least close to) proposing that success/failure be
defined as the absense/presense of a generated fault.

> Henrik

BTW a little puzzle... imagine a SOAP Message arrives at a SOAP Node
(somehow)... *none* of the headers are targetted at the node; the node
determines that it is *not* the (intended) ultimate recipient of the
message; and the node is not configured to forward the message or unable to
determine the next node along a message path. So, no header blocks are
processed, the body is not processed and the message is not forwarded. Was
the message processed successfully?

Regards

Stuart

Received on Friday, 22 February 2002 06:52:45 UTC