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


From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Thu, 16 Mar 2006 09:50:07 -0500
Message-ID: <80A43FC052CE3949A327527DCD5D6B2701986CE9@MAIL01.bedford.progress.com>
To: "Mark Little" <mark.little@jboss.com>
Cc: <paul.downey@bt.com>, <public-ws-addressing-tests@w3.org>

Hi Mark!

> 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).

Where do you see that in the WG minutes?  We didn't say that at all -
what we agreed on was this text:

  "A recipient MUST generate a wsa:InvalidAddressingHeader (see 6.4.1
  Invalid Addressing Header) fault if such a message is received;
  headers with an incorrect cardinality MUST NOT be used to populate the
  corresponding abstract properties."

This simply means that if there are multiple FaultTos, then the [fault
endpoint] property won't be populated.  It does not say, for instance,
that the value will be assumed to be anonymous, or that we would in that
case ignore ReplyTo headers.

> (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. 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.

The problem with (i) is that that would require a change to the spec.
Right now the spec simply says "if there's a problem header, don't use
that one and you should generate a fault".  Therefore the currently
spec'ed behavior is that such faults should go to the fault endpoint -
i.e. the FaultTo if valid, and the ReplyTo otherwise, which is
essentially your (ii).

It's an edge case, but if I'm doing lots of async message flows through
intermediaries, I can see this being a problem for debugging.  If I've
got FaultTo set up to go back to my async management/logging endpoint,
and some intermediary on the chain adds a spurious MessageID header, I
might want the fault to go where I told it to go, not back up the pipe
to the intermediary.

Received on Thursday, 16 March 2006 14:51:39 UTC

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