Re: issue 7911

Yves,

I think we need to break your proposal down into its constituent pieces. 
Firstly, there is the definition of the fault that is generated when/if 
an implementation detects that the first child of the [Body] does not 
match the [Action] property. I have two problems with this:

F.1) What is the point of standardizing the definition of this fault? 
Since the mismatch in question is a result of a coding error, it doesn't 
seem reasonable to expect anyone to write client code that could detect 
this fault and address the underlying problem in any meaningful way. It 
seems to me that any SOAP fault with a code of 
soap11:Client/soap12:Sender and a soap11:faultstring/soap12:Reason that 
is equivalent to "the first child of the [Body] does not match the 
[Action] property" (properly translated of course) would serve the same 
purpose.

F.2) Even if we stipulate that it is necessary to standardize the 
definition of this fault, it's not clear to me that it's within the 
scope of the WS-RA WG's charter to define what is, essentially, a 
general-purpose SOAP/WS-Addressing fault.

Secondly, there is the requirement on all WS-T resource implementations 
to check for this condition and generate the fault.

R.1) Why only WS-T? WS-Enum, WS-Eventing, and WS-Mex all have unique 
[Body] children. If it is important to check for this condition in WS-T, 
surely it is also important to check for this condition in the other 
specs as well? Even if we did modify your proposal to include WS-Enum, 
WS-Eventing, and WS-Mex, from the perspective of a general SOAP/WS-* 
stack, it seems really strange to perform this check just for these spec 
and not for any others (i.e. WS-RM, WS-Trust, etc.)

R.2) For what it's worth, my developers don't want to implement this 
check. It is not required for the correct implementation of the WS-T 
protocol (when the client sent the invalid request we left the realm of 
what the protocol defines) and, in their view, it is not likely to 
happen often enough to be worth the runtime cost.

*Counter Proposal*: Close With No Action

- gp

On 10/26/2009 6:15 AM, Yves Lafon wrote:
> On Thu, 22 Oct 2009, Gilbert Pilz wrote:
>
>> Just went to look at issue 7911 in the issues list and found a whole 
>> discussion thread in the comments section. I might have missed the 
>> entire thing if I didn't happen to stumble upon it. Could people 
>> please constrain themselves to discussing issues on the mailing list 
>> and use the comments section for major developments (i.e. new 
>> proposals, directional resolutions, etc.)?
>
> You are entirely right, I should have moved discussion here...
> Here is my proposal for resolving that issue:
>
> In 3, before the definition of the different resource operations:
>
> "If the [Body] first child is not matching the
> [Action] parameter for any defined Resource Operation, the recipient MUST
> generate a ActionAndWrapperMismatch fault"
>
> and add the fault:
> <<
> 5.4 ActionAndWrapperMismatch
>
> This fault is generated if the [Body] first child is not matching the
> [Action]
>
> [Code]    s:Sender
> [Subcode] wst:ActionAndWrapperMismatch
> [Reason]  Action and Wrapper mismatch
> [Detail]  none
>>>
>
>
>