Re: i050: FaultTo fallback to ReplyTo rule

Jonathan,
  WS-RM has the notion of multiple messages being generated for a single 
request message.  For example, one request message may generate a response 
(normal or fault) and an ACK message.  This ACK may be sent back on the 
http response flow while the response is sent over a new connection to 
some other endpoint.  So, we now have cases where messages that come back 
on the http response flow can not automatically be assumed to be related 
(as responses) to the request message.  I'm sure there will be other specs 
in the future that will probably leverage this type of behavior as well.
  In the text you've provided the client must assume that any Fault that 
comes back on the http response flow w/o any WS-Addr headers MUST be the 
response to its request.  I assume this because "unconstrained by this 
specification" to me means default back to the binding - which for http 
means sent it back on the http response flow w/o any WSA headers.  Given 
the introduction of specs like WS-RM where we can no longer assume an http 
response message is "the" response I believe it would be in the best 
interest of interoperability to require Faults in the i050 case to also 
include the WS-Addr headers.  By adding text that no wsa:FaultTo + no 
wsa:ReplyTo == anonymous URI  I believe we achieve the same semantic 
behavior you want but clear up the ambiguity introduced by messages w/o 
WSA headers.
-Doug




"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org
03/14/2005 05:20 PM

To
<public-ws-addressing@w3.org>
cc

Subject
i050: FaultTo fallback to ReplyTo rule






I took an action to rewrite Tom?s proposal 2 in terms of the rules for 
formulating a reply message.
 
Currently the Core spec says, in section 3.2:
1.      Select the appropriate EPR:
o        If the reply is a normal message, select the EPR from the 
incoming message's [reply endpoint] message addressing property. If none 
is present, the processor MUST fault.
o        Otherwise, if the reply is a fault message and the incoming 
message's [fault endpoint] message addressing property is not empty, 
select the EPR from this property. If the [fault endpoint] property is 
empty, the behavior of the recipient of the incoming message is 
unconstrained by this specification.
 
I propose amending the second bullet point as follows:
1.      Select the appropriate EPR:
o        If the reply is a normal message, select the EPR from the 
incoming message's [reply endpoint] message addressing property. If none 
is present, the processor MUST fault.
o        Otherwise, if the reply is a fault message and the incoming 
message's [fault endpoint] message addressing property is not empty, 
select the EPR from this property. If the [fault endpoint] property is 
empty, select the EPR from the incoming message's [reply endpoint] message 
addressing property.  Otherwise, if the [reply endpoint] property is 
empty, the behavior of the recipient of the incoming message is 
unconstrained by this specification.