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

On Feb 8, 2005, at 3:29 PM, Tom Rutt 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".
>
Precisely. The specification doesn't currently foster this kind of 
thing, if you expect a reply you have to put in a ReplyTo.

Marc.

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

Received on Tuesday, 8 February 2005 22:42:31 UTC