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

The problem is that simply rewording Hugo's proposal doesn't remove an 
ambiguity I see (I'm open to this just being "my problem"  though :-).  To 
me, WSA (per section 3) says Faults are replies - therefore in the absence 
of a wsa:FaultTo an implementation can choose to send Faults to the 
wsa:ReplyTo EPR.  It can also choose use the default SOAP behavior - back 
on the http response flow - because the WSA spec leaves this decision as 
"undefined".  You said "I prefer a design where WSA is transparent with 
regard to where replies and faults go unless you specifically engage 
wsa:ReplyTo and wsa:FaultTo" and I'm ok with this - so I propose that we 
actually add text to state that.
I'm guessing that you believe this is already implied - I don't believe it 
is so rather than waiting for a WS-I profile to make it explicit let's add 
to the spec now.  I think something as simple as changing:
  If the [fault endpoint] property is empty, the behavior of the recipient 
of the incoming message is undefined.
to 
  If the [fault endpoint] property is empty, the behavior of the recipient 
of the incoming message is whatever would have happened if WS-A were not 
used at all.
Or something like that (the editors can make it sound nice).
thanks,
-Dug




"Jonathan Marsh" <jmarsh@microsoft.com> 
02/08/2005 01:42 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"Hugo Haas" <hugo@w3.org>, <public-ws-addressing@w3.org>
Subject
RE: Issue i044: Definition of the rules to reply to a message in Core 3.2






We seem to be working with different definitions of ?undefined?, perhaps 
that is the source of our disconnect.
 
I propose we change ?is undefined? in Hugo?s proposal to ?is undefined by 
this specification? or ?is out of scope of this specification? to make it 
clear that we?re not removing useful behavior defined elsewhere (like the 
ability to predict where a fault goes when WSA is not engaged), but only 
adding behavior (the ability to specify where a fault goes using 
wsa:FaultTo.)
 
I prefer a design where WSA is transparent with regard to where replies 
and faults go unless you specifically engage wsa:ReplyTo and wsa:FaultTo. 
I agree with Doug that WS-A should not override the useful behavior of 
lower-level specs to make those behaviors implementation dependent, nor 
should it preclude the possibility of higher-level specs layering useful 
behavior on top of WS-A.
 
 

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, February 07, 2005 4:54 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
 

>From the client's point of view I'd like to know exactly where my 
responses (either normal responses or faults) are going to go.  Assuming 
WSA is "on" w/o a wsa:FaultTo I have no idea where my fault will go.  Per 
your suggestion it _might_ go back on the http response flow but that's 
only if the service deems it to not be a normal response but instead 
something special.  If however the service decides that faults are no 
different than responses (and per sec 3 of the WSA spec, WSA itself thinks 
faults are replies so that seems like a perfectly valid way to think of 
them) then the service is free to send the fault to the wsa:ReplyTo - its 
just a response.  What's a client to do?  Basically, wsa:FaultTo becomes 
required if I want to have a deterministic outcome.  And that's really all 
I'm looking for.  While I do have a preference as to what the semantic 
rules should be, I'm more interested in just getting the WSA spec to be 
specific about what rules people should follow and expect of a WSA 
compliant endpoint - whatever those rules may be.  So, if the WG decides 
that no wsa:FaultTo means "use default SOAP behavior (as if WSA wasn't 
"on") for Faults" then that's fine - but lets have the spec actually say 
that instead of assuming people will come to that conclusion on their own. 

I have similar concerns about replies and missing wsa:ReplyTo but we'll 
leave that one for later  :-) 
-Dug 



"Jonathan Marsh" <jmarsh@microsoft.com> 
02/07/2005 07:34 PM 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
"Hugo Haas" <hugo@w3.org>, <public-ws-addressing@w3.org> 
Subject
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