Re: Issue 292: Analysis and proposal

This note is in fulfillment of the action assigned to me on last week's 
telcon to propose a formal resolution of issue 292 [1].   On Sept. 6, I 
proposed a general direction for the solution [2], which was adopted on 
the telcon.  The wording in [2] was known to be impractically clumsy, and 
there are some traps that one can fall into in trying to present this in a 
manner that is architecturally rigorous and unambiguous.  Here is a cut at 
specific text that I propose we use to resolve this issue:

***************************************************************
From Section 1.1 (all references are to editors' copy) [3]:

<original>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC 2119]. 
</original>

<proposed>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].  See 2.6
Processing SOAP Messages for clarification of the terms "MAY fault",
"SHOULD fault", and "MUST fault" in situations where a single SOAP
message contains or results in more than one error.
</proposed>

--------------------------------------------------------------

From Section 2.6 (all references are to editors' copy) [4]:

<original>
Failure is indicated by the generation of a fault (see 5.4 SOAP
Fault). SOAP message processing MAY result in the generation of
at-most one fault. Header-related faults other than those related to
understanding SOAP header blocks (see 2.4 Understanding SOAP Header
Blocks) MUST conform to the specification for the corresponding SOAP
header block.
</original>

(note: there are no changes in the first paragraph...I just include
it here for context.)

<proposed>
Failure is indicated by the generation of a fault (see 5.4 SOAP
Fault). SOAP message processing MAY result in the generation of
at-most one fault. Header-related faults other than those related to
understanding SOAP header blocks (see 2.4 Understanding SOAP Header
Blocks) MUST conform to the specification for the corresponding SOAP
header block.

Except where order of detection is specifically indicated (as for
mustUnderstand faults above), a SOAP node MAY choose to generate any
one of the faults that would result from the processing of a message
that contains or results in more than one error.  This lattitude
applies independent of whether the errors are separately specified as
"MAY fault", "SHOULD fault", or "MUST fault".  It also applies, except
as specifically indicated, to any mixture of faults from violations of
this specification ([SOAP Part 1] and [SOAP Part 2]), violations of
the specifications of SOAP features, and/or to faults detected by a
SOAP binding.  For example, a node encountering a situation in which
it "MAY fault" due to misuse of a SOAP feature: (a) MAY reflect that
fault and terminate processing without further checking the message
for other errors; (b) MAY continue and select a different fault to be
generated; or (c) if none of the errors is indicated as "MUST fault",
MAY decline to fault at all, and instead continue with successful 
processing of the message.
</proposed>

***************************************************************

I propose that we vote to adopt the above on during the Wed. call. 
Thank you.

Noah


[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x292
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0057.html
[3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#notation
[4] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#procsoapmsgs


------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 16 September 2002 22:41:06 UTC