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

Microsoft prefers the status quo in that regard ;-).

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM]
> Sent: Tuesday, February 08, 2005 10:49 AM
> To: Jonathan Marsh
> Cc: Doug Davis; Hugo Haas; public-ws-addressing@w3.org
> Subject: 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 20:32:51 UTC