Re: NEW ISSUE: Misalignment of treatment of reply messages and fault messages

+1

Another way to look at this is to distinguish between the information 
set received by the receiver and what's actually on the wire.  The 
information set received will always contain a reply-to: and a fault-to: 
address.  If they're not present on the wire, "anonymous" is assumed.

Doug Davis wrote:

>
> Hugo,
>   I believe there's another option (say 1.5), allow wsa:ReplyTo and 
> wsa:FaultTo
> to be optional (like 1) but the implied semantics are equivalent to 
> them being there
> with the anonymous URI.  Its basically the same as 1, in that the 
> message will still
> go back on the http response flow, but clearly states that the 
> response will still
> contain the proper WSA headers and what their values will be.   I 
> think this is
> important because I believe that the sender of the original message 
> will probably
> want WSA to be "on" for the response/fault since it was used on the 
> request.
> thanks,
> -Dug
>
>
>
> *Hugo Haas <hugo@w3.org>*
> Sent by: public-ws-addressing-request@w3.org
>
> 02/15/2005 10:14 AM
>
> 	
> To
> 	public-ws-addressing@w3.org
> cc
> 	
> Subject
> 	NEW ISSUE: Misalignment of treatment of reply messages and fault 
> messages
>
>
>
> 	
>
>
>
>
>
>
> -=- Title -=-
>
> Misalignment of treatment of reply messages and fault messages
>
> -=- Description -=-
>
> Section 3 of the core spec[1] presents faults as a type of reply:
>
>  A reply in this case can be either an application message, a fault,
>  or any other message.
>
> However, normal replies and faults are treated differently by WS
> Addressing processors, as the rules expressed in issue i044's
> resolution[2] show:
> - for a reply to be sent back, the incoming message MUST have
>  wsa:ReplyTo header;
> - the meaning of wsa:FaultTo, OTOH, is that if present, it specifies
>  where faults should go; otherwise, other rules (e.g. the MEP's or the
>  binding's) apply.
>
> -=- Justification -=-
>
> The discussion around i044 (see thread starting at [3]) has shown
> that:
> - replies and faults work under different models/philosophies in the
>  case of a reply to an incoming message: for the latter, it when
>  wsa:FaultTo is absent, the processor behaves just as if Addressing
>  wasn't in use; for the former, the absence of wsa:ReplyTo is a
>  violation of the Addressing specification.
> - this difference may cause confusion.
>
> As this difference is unjustified in the spec, I propose that we align
> the rules for faults and normal replies.
>
> -=- Target -=-
>
> Core
>
> -=- Proposal -=-
>
> There are 4 ways to go about this issue, which I'll list from my
> favorite to my least favorite one. For each proposal, I am giving an
> example message of a valid request message in a classical
> request-response scenario over HTTP, where either a normal reply or a
> fault may be returned.
>
> - Proposal 1: make wsa:ReplyTo optional in case of a message to which
>  a reply is expected; this way, both wsa:FaultTo and wsa:ReplyTo can
>  be absent and other rules (e.g. the binding rules) may apply.
>
>  In this case, if a message is sent to a service without a
>  wsa:ReplyTo in our scenario, the reply goes back to the sender over
>  the HTTP response, just as if the person wasn't using addressing.
>
>  The following would be valid whether it triggers a fault or whether
>  it's processed normally:
>
>    <S:Envelope>
>     <S:Header>
>       <wsa:Action>
>                  http://example.com/action
>       </wsa:Action>
>     </S:Header>
>     <S:Body>
>       <foo/>
>     </S:Body>
>    </S:Envelope>
>
>  One MAY want to add a wsa:ReplyTo or a wsa:FaultTo if needed, i.e.
>  if one wanted to have the reply or the fault be sent on another
>  channel than the HTTP response.
>
> - Proposal 2: make wsa:FaultTo mandatory for messages which can
>  trigger faults.
>
>  In this case, when a fault MAY be received (i.e. when the MEP
>  explicitly says that a fault MAY be sent back[4]), then the incoming
>  message MUST contain a wsa:FaultTo, and it's an error if it doesn't.
>
>  This basically aligns wsa:FaultTo with what we currently do for
>  wsa:ReplyTo.
>
>  In our scenario, a valid message would be:
>
>    <S:Envelope>
>     <S:Header>
>       <wsa:Action>
>                  http://example.com/action
>       </wsa:Action>
>       <wsa:ReplyTo>
>                  http://www.w3.org/@@@@/@@/addressing/role/anonymous
>       </wsa:ReplyTo>
>       <wsa:FaultTo>
>                  http://www.w3.org/@@@@/@@/addressing/role/anonymous
>       </wsa:FaultTo>
>     </S:Header>
>     <S:Body>
>       <foo/>
>     </S:Body>
>    </S:Envelope>
>
>  Omitting wsa:ReplyTo or wsa:FaultTo would be an error (required
>  message addressing property missing).
>
> - Proposal 3: leave wsa:ReplyTo and wsa:FaultTo as is, but clearly
>  point out the difference of behavior between the two and the
>  motivation behind this.
>
>  I believe that a justification for proposal 3 -- and therefore for
>  the difference between wsa:ReplyTo and wsa:FaultTo -- would be that
>  there are times when one doesn't expect to receive a fault, and yet
>  a fault occurs. However, I think that this is an argument for
>  proposal 1.
>
>  In our scenario, the following would be valid:
>
>    <S:Envelope>
>     <S:Header>
>       <wsa:Action>
>                  http://example.com/action
>       </wsa:Action>
>       <wsa:ReplyTo>
>                  http://www.w3.org/@@@@/@@/addressing/role/anonymous
>       </wsa:ReplyTo>
>     </S:Header>
>     <S:Body>
>       <foo/>
>     </S:Body>
>    </S:Envelope>
>
>  One MAY want to add a wsa:FaultTo if needed, i.e. if one wanted to
>  the fault to be sent on another channel than the HTTP response.
>
>  Omitting wsa:ReplyTo would be an error (required message addressing
>  property missing).
>
> - Proposal 4: status quo.
>
>  An example of valid message is in proposal 3.
>
>  This is essentially saying that this is a non-issue.
>
> Cheers,
>
> Hugo
>
>  1. 
> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html#_Toc77464322
>  2. 
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0091.html
>  3. 
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0036.html
>  4. http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-rules
> -- 
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
>