new wsa:FaultTo text

Actually, another possibility is that no wsa:FaultTo means "treat the 
fault as the response and send it where ever the response would go".  Is 
either of these the correct intent? 
thanks,
-Dug


__________________

All,
  just noticed this:

i029 
Disallowing Faults ? search 
core - design - closed

Description 
wsa:FaultTo "may be absent if the sender cannot receive fault messages 
(e.g. is a one-way application message)." But it also says that in the 
absence of wsa:FaultTo the wsa:ReplyTo/From may be used. So, how does a 
sender really say that it doesn't want ANY fault messages at all but still 
be allowed to specify a wsa:From? 
Origin 
Doug Davis 
Owner 
Harris Reynolds 
Resolution2004-12-07 
Add "when present" to the second sentence of [fault endpoint] of Core 
section three; remove third to fifth sentences of [fault endpoint of Core 
section three (so as to not imply a processing model); make similar 
changes in [reply endpoint] definition. 

And the new text for wsa:FaultTo says:

[fault endpoint] : endpoint reference (0..1) 
An endpoint reference that identifies the intended receiver for faults 
related to this message. When formulating a fault message as defined in 
3.2 Formulating a Reply Message, the sender MUST use the contents of the 
[fault endpoint], when present, of the message being replied to to 
formulate the fault message. If this property is present, the [message id] 
property is REQUIRED.

So, what does it mean when the wsa:FaultTo header is not present?  Does it 
mean the client will not get back any faults at all or does the fault get 
sent back to the wsa:ReplyTo EPR?  Probably not since the defaulting back 
to wsa:ReplyTo is not mentioned any more.  So, what should the client 
expect in terms of where Faults will go when wsa:FaultTo is not present? 
As the text stands now I would guess that  no wsa:FaultTo is the same as 
wsa:FaultTo == anonymousURI  - meaning send faults back on the HTTP 
response flow - is this the new intent?

thanks,
-Dug