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