W3C home > Mailing lists > Public > public-ws-addressing-tests@w3.org > March 2006


From: Mark Little <mark.little@jboss.com>
Date: Thu, 16 Mar 2006 09:26:24 +0000
Message-ID: <44192F40.5040306@jboss.com>
To: Glen Daniels <gdaniels@sonicsoftware.com>
CC: paul.downey@bt.com, public-ws-addressing-tests@w3.org

Mark Little wrote:
> I agree that we need to test for this and I also think the 
> specification should be more explicit on how to deal with errors 
> during the processing of the WSA header information. What I'm still 
> unclear about is what algorithm to use in this case. There appear to 
> be only two:
> (i)  it does make sense to say (as the last WG minutes indicate) that 
> if you encounter an error at any point in the processing, then don't 
> trust anything at all in the WSA header and send a fault back to the 
> sender (anonymous).
> or
> (ii) if an error happens after processing part of WSA we could try and 
> use that information to send back fault information (assuming we've 
> parsed wsa:ReplyTo or wsa:FaultTo).
> The problem with (i) is that the receiver may not be expecting to get 
> error messages on that channel. 

Scratch that. As Kevin just reminded me, the sender should expect errors 
during transmission for things like MU anyway.

> The advantage is that it's simple to reason about and can be tested by 
> everyone.
> The problem with (ii) is that we can't tell if the information we've 
> already parsed is valid and we also can't guarantee that WSA header 
> information is sent and parsed in the same way by all senders or 
> receivers. This makes a deterministic test impossible to achieve. The 
> advantage is that we MAY be able to send back errors to an endpoint 
> that can actually deal with them.
> I think we're all agreed that this is an edge case situation, so we 
> probably shouldn't optimise the specification (or our tests) for it. 
> As such, I'm more in favour of (i) than (ii) because of its simplicity.
> Mark.
> Glen Daniels wrote:
>>>> One way or another we should definitely add some tests.       
>>> feel free to submit test cases, I think the format is fairly clear. 
>>> At this stage I think they'd be 'OPTIONAL' or 'INFORMATIONAL'
>>> unless they're aimed specifically at WSDL CR.
>> Er... I think we should perhaps gather opinions on this.
>> The problem is that the results for WSO2 -> just-about-everyone are
>> actually (assuming our interpretation is correct) logs demonstrating
>> IMPROPER behaviour according to our current spec.  If I get a message
>> with no FaultTo, a ReplyTo of "none", and a duplicate To header, we
>> should NOT be getting a fault back on the HTTP backchannel.
>> So, we should really probably fix the test assertions (by adding
>> something like "(no ReplyTo) OR (ReplyTo == anonymous)") for a bunch of
>> these tests, and also add the new one I described (I'll submit that in
>> the correct format).  I don't think this should be OPTIONAL or
>> I don't want to hold things up, but nor do I want a test suite that
>> doesn't match our spec.
>> --Glen
Received on Thursday, 16 March 2006 09:25:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:02 UTC