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

I think I understood you.  I am suggesting that we don't advise users of
WSA to avoid the unconstrained bit of the spec.  Though that part is
unconstrained by WS-A, there is no reason to think it's dangerous and
warn people off.  At least you haven't proved it to be so yet...

 

For instance, say I have a deployed service with 10 in-out operations.
I decide to upgrade my service so that one of those operations accepts
and processes ReplyTos.  Now I'm a WS-A user.  Under your suggestion, I
would be encouraged to also add FaultTos, not just to the operation I
modified, but to the other 9 operations as well.  If explicit FaultTos
are a good idea, explicit ReplyTos probably are as well, so I should add
those to the remaining 9 operations as well.  Seems like a lot of
overhead for a small change to one operation.  It's hard to see why the
practice I used yesterday to send replies and faults has somehow become
dangerous today because I'm now a WS-A user.

 

________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, February 07, 2005 12:37 PM
To: Jonathan Marsh
Cc: Hugo Haas; public-ws-addressing@w3.org
Subject: RE: Issue i044: Definition of the rules to reply to a message
in Core 3.2

 


Jonathan, 
  I think you might have misread my note - or perhaps I wasn't clear. 
I wasn't suggesting that WSA should say what an impl. should do 
in the absence of a wsa:FaultTo header but rather suggesting 
that WSA should encourage users of WSA to avoid this "unconstrained" 
bit of the spec and be explicit in their messages and include a 
wsa:FaultTo. 
-Dug 




"Jonathan Marsh" <jmarsh@microsoft.com> 

02/07/2005 11:56 AM 

To

Doug Davis/Raleigh/IBM@IBMUS, "Hugo Haas" <hugo@w3.org> 

cc

<public-ws-addressing@w3.org> 

Subject

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