W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Fw: Proposed resolution for Issue 50 (Misallignment of faut to and reply to )

From: Francisco Curbera <curbera@us.ibm.com>
Date: Thu, 3 Mar 2005 13:29:58 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-ID: <OF881302FB.60EB45CC-ON85256FB9.0065910C-85256FB9.00659F28@us.ibm.com>
Resending to the list...

----- Forwarded by Francisco Curbera/Watson/IBM on 03/03/2005 01:29 PM
-----
                                                                                                                                 
                      Francisco Curbera                                                                                          
                                               To:      David Hull <dmh@tibco.com>                                               
                      03/03/2005 01:29         cc:                                                                               
                      PM                       From:    Francisco Curbera/Watson/IBM@IBM01                                       
                                               Subject: Re: Proposed resolution for Issue 50 (Misallignment of faut to and       
                                               reply  to )(Document link: Francisco Curbera)                                     
                                                                                                                                 



David,

I don't understand your point. Who defines this binding? The deployer of
the service receiving the message? This is the opposite of the model we
have now, where the sender specifies where replies/faults should go. This
is the base for supporting asynch communication.  Are you proposing that
the receiver make this decision instead?

The question here is what is the "right" default endpoint for sending
faults back. Defaults should capture common and safe assumptions, not
arbitrary choices. IMO the only reasonable default is replyTo because there
you positively know that the sender is ready to accept a message;
everything else is dangerous speculation. Defaulting to anonymous is risky
because anonymous may not have any meaning for an arbitrary request. If the
request message specifies that the reply be sent to a new endpoint, it
seems unlikely that the sender would intend faults to be returned
synchronously over the same connection.

Anonymous seems like a badly chosen default to me. As for the binding
dependent approach I just don't get it, sorry if I am being thick.

Paco



                                                                                                                                         
                      David Hull                                                                                                         
                      <dmh@tibco.com>                 To:       public-ws-addressing@w3.org                                              
                      Sent by:                        cc:       "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>              
                      public-ws-addressing-req        Subject:  Re: Proposed resolution for Issue 50 (Misallignment of faut to and       
                      uest@w3.org                      reply  to )                                                                       
                                                                                                                                         
                                                                                                                                         
                      03/01/2005 09:00 PM                                                                                                
                                                                                                                                         




Having thought it over, I still prefer this formulation:
      Bindings MAY define a default destination for faults and/or replies.
      A missing ReplyTo or FaultTo is interpreted according to the binding.
            E.g., SOAP/HTTP defaults both to the backchannel.
            something over email might default one or both to the From
            address.
            other bindings may require both always to be present -- results
            are undefined otherwise
      You could also use the anonymous endpoint designation to explicitly
      to invoke this default behavior, if you like that sort of thing.
      Sort of a "this page intentionally left blank".  But if there is no
      semantic difference between missing and anonymous, I'm not sure what
      anonymous is bringing to the party.
We could also make the over-arching rule that a missing FaultTo defaults to
the ReplyTo (which may in turn default as above), but I'm not sure this is
a good idea.  For example, what does it mean for robust out-only, where
there may be a fault but will not be a reply?  It would also interfere with
bindings that have naturally different destinations for faults and
replies.  I can't name such a binding, but I'm not willing to say it can't
exist.

Tom Rutt wrote:

      As currently specified, an EPR is allowed to have th value
      “anonymous” for the wsa:ReplyTo element. In this case, the reply goes
      back to the sender over the HTTP response, just as if not using
      addressing.

      I would like to have an optimization (just as we did for wsa:To) that
      absence of wsa:ReplyTo is semantically equivalent to using the
      “anonymous” value.

      Also: we almost agreed to have missing FaultTo implying use of
      ReplyTo when a fault is to be sent.

      Proposal to resolve Issue 50:

      First cut at text to add to the spec in definition of wsa:ReplyTo:
      “
      In the case of a message for which a reply is expected, the implied
      semantics of wsa:ReplyTo not present are equivalent to it being
      present with the anonymous URI.
      “

      In the definition for wsa:FaultTo, add the statement:
      “
      If wsa:FaultTo is absent, a Fault may be sent to the value (explicit
      or through the implicit indication of “anonymous”) for wsa:ReplyTo..



Received on Thursday, 3 March 2005 18:34:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT