Re: Issue 182: Fault Code restriction: "At Most One Fault Proposal"

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. What he points out is that
the spec is already quite clear on when a SOAP node MUST
generate a Fault (see his table) but that there were also
cases where the semantics were "MAY" or "SHOULD" and
that the semantics of header blocks externally specified
seemed to be perfectly within their prerogative to
choose the terms MAY and/or SHOULD in addition to MUST.

Hence, a generalized "if processing is unsuccessful..."
really has no business saying that a Fault MUST be generated,
especially as this would conflict with other sections of
the specification.

My understanding of our discussion yesterday was that
this issue was all about the cardinality (exactly one Fault)
and not about whether or not a fault would be generated.

Orthogonal to the above is the point Noah raises below. The
SOAP spec goes out of its way to say nothing whatsoever
about what a SOAP node *does* with a "generated" Fault.
Hence, I don't believe that there is, at present, any
need for the phrase under consideration to address "being
able to tell whether a request is proceeding successfully...".

Cheers,

Chris

noah_mendelsohn@us.ibm.com wrote:

> +1 (at least that's my initial reaction.)  Can't quite pin down why, but 
> I'm nervous about not being able to tell the difference between a request 
> that is proceeding successfully, but taking a seemingly unbounded amount 
> of time, but one which has silently failed.  Mandating that there is 
> always some indication of failure, as you propose, seems to deal with that 
> concern.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
> Sent by: xml-dist-app-request@w3.org
> 02/21/2002 11:51 AM
> 
>  
>         To:     "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        RE: Issue 182: Fault Code restriction: "At Most One Fault Proposal"
> 
> 
> 
> Thanks Stuart for writing this up - I realize the amount of work it is.
> I think, however, that the text we are discussing has a slightly
> different purpose than what you are implying. Section 2.6 "Processing
> SOAP messages" talks about how to process *any* SOAP message: you find
> the pieces targeted at you, you must do the mU ones, may do the rest,
> and then process according to the semantics of these pieces.
> 
> The point I was bringing up yesterday is that *if* the rules and
> semantics of a block (or the body) are not met then we must guarantee
> that the processing does not appear to be successful. The reason why
> this has an implication on interoperability is that if I don't know that
> a SOAP processor is going to fail in a specific situation, I have no
> mechanism for reliably determining the outcome of the processing and
> hence can not possibly expect to interoperate.
> 
> While the specific fault codes you list below describes specific cases,
> they do not cover the general case of the processing model which invokes
> the term "understand". It is perfectly valid for a header block or a
> body to define states that are not clear fault states, call them warning
> states, say, that do not result in a SOAP fault being generated. While
> the SOAP processing is indifferent to such states, if the semantics
> calls for a fault, we (as the SOAP processor) must guarantee that SOAP
> processing is deterministic.
> 
> Maybe we can address this doing something like this (including the
> paragraph above the one we are discussing as it highly related):
> 
> "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."
> 
> The idea of this is that we have symmetry between the MUST process
> (going from SOAP to app-defined  specification) and MUST fault (going
> from app-defined specification to SOAP).
> 
> Comments?
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 
> 
>>Conclusion
>>----------
>>The SOAP processing model [3b] is clear about the termination 
>>of message
>>processing only in the case of mU faults. This is moot for 
>>DTDNotSupported
>>and versionMismatch faults where processing is unlikely to 
>>advance as far as
>>processing the content of the envelope.
>>
>>For sender, receiver and DataEncodingUnknown faults, as far as 
>>I can tell,
>>the processing model [3b] does not explicitly prohibit some 
>>effort being
>>made to partially process a message - this is probably an 
>>oversight (rather
>>than a subtelty) and should be fixed.
>>
>>In general the circumstances under which each type of fault is 
>>generate is
>>stated and a MUST,MAY or SHOULD imperative associated with the 
>>corresponding
>>fault generation. MAY's and SHOULD's are used which leave open 
>>the potential
>>for a failure to arise that does not generate a fault. Also, there are
>>clearly more potential failures possible than are covered in 
>>the spec. which
>>also leave potential for faults not to be generated (due to omission -
>>because full enumeration is not practical).
>>
>>SOAP also provides for extensions to specify their own fault generation
>>behaviour, which also leave open the possibility that 
>>extensions also use
>>the imperatives MAY and SHOULD in conjuction with the 
>>generation of faults.
>>
>>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.
>>
>>Regards
>>
>>Stuart Williams
>>--
>>[1]  http://www.w3.org/2000/xp/Group/xmlp-issues.html
>>[2]  http://www.ietf.org/rfc/rfc2119.txt
>>
>>[3]  http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html
>>[3a] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#muprocessing
>>[3b] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#procsoapmsgs
>>[3c] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#reltoxml
>>[3d] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#envvermodel
>>[3e] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#faultcodes
>>
>>
>>[4]  http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html
>>[4a] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#encfaults
>>[4b] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#IDAL53U
>>[4c] 
>>http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#rpcfaults
>>
> 
> 
> 
> 
>

Received on Thursday, 21 February 2002 13:36:10 UTC