W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

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

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 21 Feb 2002 00:20:23 -0000
Message-ID: <5E13A1874524D411A876006008CD059F19299B@0-mail-1.hpl.hp.com>
To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
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 Wednesday, 20 February 2002 19:20:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT