RE: Use of FaultTo when propagating WS-A Faults

I am becoming increasingly concerned about this idea of using someof the WS-A headers even when the message is faulty in WS-A terms.
 
If we follow Dave Hull's described situation, then we have the ingredients for a nasty DDoS scenario - send out a stack of messages to a range of servers, all of them with FaultTo pointing to the target machine, and no Action - the target machine will be bombarded with Fault messages. Not a good thing.
 
I prefer the idea of a binary switch - we are using WS-A or we are not using WS-A - if the message is WS-A faulty (eg: no Action) then we are NOT using WS-A, so we should not be using the FaultTo address. We fault using the back-channel (if there is one), or we drop the message in the bit-bucket (possibly logging it). Note that the back-channel may be the HTTP return channel, or some other understood back-channel as defined by the server's circumstances.
 
I think of this as being similar to the situation we discussed in the Async group in Palo Alto - we have not yet accepted the WS-A headers, so we are not in the position of being prepared to use them.
 
Fair enough?
 
Tony

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of David Hull 
	Sent: Sat 16-Jul-05 4:28 
	To: David Orchard 
	Cc: public-ws-addressing@w3.org 
	Subject: Re: Use of FaultTo when propagating WS-A Faults
	
	
	What if we really are in a one-way scenario and "anonymous" is undefined?  It seems wrong not to try to send a fault to the [fault endpoint] if it exists.  It seems particularly wrong simply to drop such a message on the floor because it happened to lack an [action].
	
	David Orchard wrote: 

		Related to LC76, we came to the agreement that ReplyTo would NOT be used when a message contains an imperfect set of WS-A Headers, like a missing WS-A: Action.

		 

		What about the use of FaultTo for a Fault?  Imagine the scenario where FaultTo is non-anonymous and Action is missing.  The receiver decides to Fault (perhaps because mU was on a WS-A header).  

		 

		I think the correct behaviour is that the FaultTo should not be used for propagating the Fault, because the FaultTo is part of the overall WS-A set of headers which aren't valid.  But that does seem a little counter-intuitive.

		 

		If the FaultTo is ignored, then Fault would probably be sent back over an HTTP Connection if one exists.  This is like changing the faultTo to become anonymous.  This seems to be yet another scenario where even though the sender believes it is a one-way message, it will allow for a soap fault in the response if it wants as much information as possible.

		 

		Cheers,

		Dave