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

+1

Williams, Stuart wrote:

> Background
> ----------
> 
> During the discussion of Issue 182 [1] on todays telcon, I proposed a change
> to the current proposal to resolve i182 [1] (from the issues list):
> 
> "If processing is unsuccessful, exactly one fault MUST be generated by the
> node. Header-related faults other than mustUnderstand faults MUST conform to
> the specification for the corresponding SOAP header block."
> 
> My proposal is to ed change is to change "exactly one fault MUST" to
> "at-most one fault MAY" ie:
> 
> "If processing is unsuccessful, at-most one fault MAY be generated by the
> node. Header-related faults other than mustUnderstand faults MUST conform to
> the specification for the corresponding SOAP header block."
> 
> Concern was expressed that we need to be consistent with the SOAP message
> processing model and that we need to be clear about when faults are
> generated. As a consequence I have the action to review the existence of
> imperatives, particularly MUST with respect to the generation of specific
> faults (see follow-up below).
> 
> My conclusion, (see conclusion below) supports the amended resolution
> (YMMV).
> 
> Proposal Rationale
> ------------------
> I expressed some discomfort with the first MUST on the grounds that RFC 2116
> [2], which we cite normatively, recommends:
> 
> <quote>
> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> 
> </quote>
> 
> My concern is that it is not apparent that, in general, the failure to
> generate a fault leads to an interoperability problem and therefore the MUST
> imperative seems too strong.
> 
> Followup:
> ---------
> 
> 			Decription of
> Fault			when generated?	Imperative used
> ----------------------------------------------------
> mustUnderstand	yes			MUST 	[3a,3b]
> DTDNotSupported	yes			MUST	[3c]
> versionMisMatch	yes			MUST	[3d]
> sender (general)	yes (general)	Unspecified [3e]
> sender/enc:MissingID
> 			yes			SHOULD [4a]
> sender/enc:UntypedValue
> 			yes			MAY [4a]
> sender/rpc:ProcedureNotPresent
> 			yes			MUST [4c]
> sender/rpc:BadArgs
> 			yes			MUST [4c]
> receiver(general)	yes (general)	Unspecified	[3e]
> 						SHOULD [4c]
> DataEncodingUnknown
> 			yes			SHOULD [4c]
> 
> [Spec. extracts follow the references below]
> 
> 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
> 
> In Part 1 [3]:
> 
> Re: mustUnderstand Faults, 
> 
>   Section 2.4 "Understanding SOAP Headers" [3a] states:
> 
>   "For every mandatory SOAP header block targeted to a node, that 
>   node MUST either process the block or not process the SOAP message 
>   at all, and instead generate a fault (see 2.6 Processing SOAP Messages 
>   and 4.4 SOAP Fault)."
> 
>   Section 2.6 "Processing SOAP Messages" [3b]
> 
>   "3. If one or more of the header blocks identified in the preceding 
>       step are not understood by the node then generate a single SOAP 
>       MustUnderstand fault (see 4.4.6 MustUnderstand Faults). If such 
>       a fault is generated, any further processing MUST NOT be done. 
>       Faults relating to the existence or contents of the body MUST NOT 
>       be generated in this step."
> 
>   and (the text targeted for replacement by this resolution)
> 
>   "If processing is unsuccessful, exactly one fault MUST be 
>    generated by the node. Header-related faults other than 
>    mustUnderstand faults (see 4.4 SOAP Fault) MUST be SOAP 
>    Sender or DataEncodingUnknown faults (see 4.4.5 SOAP 
>    Fault Codes) and MUST conform to the specification for 
>    the corresponding SOAP header block. Faults relating to 
>    the body MUST be SOAP Sender or DataEncodingUnknown 
>    faults (see 4.4.5 SOAP Fault Codes)."
> 
> Re: DTDNotSupported Faults:
> 
>     Section 3 "Relation to XML" [3c] states:
> 
>     "A SOAP message MUST NOT contain a Document Type 
>      Declaration. On receipt of a SOAP message containing 
>      a Document Type Declaration, a SOAP receiver MUST 
>      generate a fault (see 4.4 SOAP Fault) with a fault 
>      code of "DTDNotSupported". A SOAP message SHOULD NOT 
>      contain processing instruction information items. 
>      A SOAP receiver MUST ignore processing instruction 
>      information items in SOAP messages it receives."
> 
> Re: VersionMismatch faults:
> 
>     Section 4.1.2 "Envelope Versioning Model" [3d] states
> 
>     "SOAP does not define a traditional versioning model 
>      based on major and minor version numbers. If a SOAP 
>      message is received by a SOAP 1.2 node in which the 
>      document element information item does NOT have a 
>      namespace name of http://www.w3.org/2001/12/soap-envelope 
>      the SOAP node MUST treat this as a version error 
>      and generate a VersionMismatch SOAP fault (see 
>      4.4 SOAP Fault). See A Version Transition From 
>      SOAP/1.1 to SOAP Version 1.2 for further details.
>      
>      Any other malformation of the message structure MUST 
>      be treated as a Sender SOAP fault"
> 
> 
> Re: Sender faults:
>      Section 4.4.5 "SOAP Faultcodes" [3e] states:
> 
>      "A Sender fault code indicates that the message was 
>       incorrectly formed or did not contain the appropriate
>       information in order to succeed. For example, the 
>       message could lack the proper authentication or 
>       payment information. It is generally an indication 
>       that the message should not be resent without change. 
>       See also 4.4 SOAP Fault for a description of the SOAP 
>       fault detail sub-element."
> 
> Re: Receiver faults:
>      Section 4.4.5 "SOAP Faultcodes" [3e] states:
> 
>      "The Receiver fault code indicates that the message 
>       could not be processed for reasons not directly 
>       attributable to the contents of the message itself 
>       but rather to the processing of the message. For 
>       example, processing could include communicating 
>       with an upstream SOAP node, which did not respond. 
>       The message may succeed at a later point in time. 
>       See also 4.4 SOAP Fault for a description of the 
>       SOAP fault detail sub-element."
> 
> In Part 2:
> 
> Re: env:Sender/enc:MissingID and env:Sender/enc:UntypedValue
> 
>      Section 3.2 "Decoding Faults" [4a] states:
> 
>      "During deserialization a SOAP receiver: 
> 
>          SHOULD generate an env:Sender SOAP fault with a 
>          subcode of enc:MissingID if a referencing accessor 
>          to a non-existent multi-reference value is found;
> 
>          MAY generate an env:Sender SOAP fault with a subcode 
>          of enc:UntypedValue if unable to determine the type 
>          of a value (e.g. a schema being unavailable when 
>          required to determine the type)."
> 
> 
> Re: Faults during RPC processing.
>        Section 4.1 "RPC and SOAP Body" [4b] states:
> 
>       "Applications MAY process invocations with missing parameters 
>        but also MAY return a fault."
> 
> 	I think this needs clarifying because it can be interpreted as 
> 	allowing both a response and *return* of a fault! Suggest:
> 
>       "Applications MAY process invocations with missing parameters 
>        or MAY generate a fault and MUST NOT do both."
> 
> 
> 	Section "4.3 RPC Faults" states [4c]
> 
> 	"Errors arising during RPC invocations are reported according 
>        to the following rules (in decreasing order of precedence):
> 
>          An env:Receiver fault SHOULD be generated when the receiver 
>          cannot handle the message because of some temporary condition, 
>          e.g. when it is out of memory.
> 
> 	   An env:DataEncodingUnknown fault SHOULD be generated when the 
>          arguments are encoded in a data encoding unknown to the receiver.
> 
> 	   An env:Sender fault with a subcode value of
> rpc:ProcedureNotPresent 
> 	   fault MUST be generated when the receiver cannot find the
> procedure
> 	   specified.
> 
> 	   An env:Sender fault with a subcode value of rpc:BadArguments 
> 	   fault MUST be generated when the receiver cannot parse the 
> 	   arguments or when there is a mismatch between what the 
> 	   receiver expects and what the sender has sent.
> 
> 	Other faults arising in an extension or from the application SHOULD
> be 
> 	generated as described in [1](SOAP Faults).
> 
> 
>

Received on Thursday, 21 February 2002 08:39:38 UTC