RE: Issue i044: Definition of the rules to reply to a message in Core 3.2

I suspect the intent is more along the lines of "is unconstrained by this specification" (or at least, I'd prefer those words.)  I'd expect in the absence of FaultTo that most faults would be sent wherever they would have if WS-A was not in use.

It's WS-A's business to introduce a specific feature (FaultTo) and its behavior.  It's not WS-A's business to constrain what might happen when WS-A features are not engaged.  Nor unduly limit the ability of future specs to build on this feature.  I think the rules Hugo proposes do this pretty cleanly.
 
________________________________________
From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, February 07, 2005 5:40 AM
To: Hugo Haas
Cc: public-ws-addressing@w3.org
Subject: Re: Issue i044: Definition of the rules to reply to a message in Core 3.2


Hugo wrote on 02/07/2005 04:44:08 AM:
...
> 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 undefined.

In particular, the "... is undefined." in the last sentence. 
I read this to mean that as the sender of the incoming message I 
can not make any assumption about where any possible Fault would go 
if I did not include a wsa:FaultTo EPR in the incoming message. 
Is this correct?  If so, does this not have the effect of making the wsa:FaultTo 
EPR required for all cases except in a one-way fire-n-forget scenario? 
If so, that's ok (I guess :-), but I think it would be helpful to 
encourage people (with a 'SHOULD' someplace) to include a wsa:FaultTo 
so that they avoid 'undefined' behavior and risk interop issues. 
-Dug

Received on Monday, 7 February 2005 17:03:15 UTC