- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Thu, 21 Feb 2002 00:20:23 -0000
- 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 UTC