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

Marc Hadley wrote:

>
> 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 ?

What about the "synchronous reply" case where the server knows it is 
receiving the request message for a wsdl request-response operation 
bound to a soap/httpPost request.  Since the response (or fault) in this 
case would be carried by the http Post response, the replyTo is 
unnecessary.  This is one case where "wsa:replyTo" missing could have 
the same semantics as
wsa:replyTo="anonymous".

Tom Rutt
Fujitsu

>
> 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.
>
>
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 8 February 2005 20:30:20 UTC