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

Hugo, a nice summary of the problem statement. My preference would be to 
make ReplyTo optional too, i.e., option 1 in your list of 4 solutions.

Mark.

Hugo Haas wrote:

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