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

I think we're on the same page semantically.  I believe the difference 
is between saying

    * missing => anonymous => binding-specified

and

    * missing => binding specified

For me the latter wins. /Entia non sunt multiplicanda praeter necessitatem/.

Hugo Haas wrote:

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