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

* David Hull <dmh@tibco.com> [2005-03-01 21:00-0500]
> 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.
>          o E.g., SOAP/HTTP defaults both to the backchannel.
>          o something over email might default one or both to the From
>            address.
>          o other bindings may require both always to be present --
>            results are undefined otherwise

Absolutely. I'll add that, the same way you may want to say "send any
faults the way the MEP/binding/contract told you to", you will want in
the general case (SOAP request-response over HTTP) to say "send the
response the way the MEP/binding/contract told you to". I do not see
why responses and faults have to be differentiated when it comes down
to this behavior.

Again, to reuse the email analogy I used yesterday, I don't set the
Reply-To header in all of my emails, only when I want to deviate from
the standard procedure which is to send the reply to somebody else.

So, to put it clearly, I'd like to put proposal #1, as amended the way
I think it got support when we talked about it previously, on the
table as a proposed resolution for i050:

- Make wsa:ReplyTo optional.
- Say that the lack of wsa:ReplyTo sets [reply endpoint]'s value to an
  EPR whose [address] value is
  http://www.w3.org/2005/02/addressing/role/anonymous
- Say that the lack of wsa:FaultTo sets [fault endpoint]'s value to an
  EPR whose [address] value is
  http://www.w3.org/2005/02/addressing/role/anonymous

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

I think that this is already said in[1]:

  Requests whose [reply endpoint], [source endpoint] and/or [fault
  endpoint] use this address MUST provide some out-of-band mechanism
  for delivering replies or faults (e.g. returning the reply on the
  same transport connection). This mechanism may be a simple
  request/reply transport protocol (e.g., HTTP GET or POST). This URI
  MAY be used as the [destination] for reply messages and SHOULD NOT
  be used as the [destination] in other circumstances.

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

I also am unsure about wsa:FaultTo inheriting wsa:ReplyTo's if it's
absent, especially as it is something that we removed as a result of
i029[2]. So I'd prefer not to do that.

Cheers,

Hugo

  1. http://www.w3.org/TR/2005/WD-ws-addr-core-20050215/#_Toc77464322
  2. http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item20
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/