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

I think we've already gone beyond "a design where WSA is transparent 
with regard to where replies and faults go unless you specifically 
engage wsa:ReplyTo and wsa:FaultTo" by requiring (with a MUST) that 
ReplyTo be present in messages to which a reply is expected. Are you 
suggesting that we revisit this ?

Marc.

On Feb 8, 2005, at 1:42 PM, Jonathan Marsh wrote:

> 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
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Tuesday, 8 February 2005 18:48:45 UTC