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

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.

+1 on this ammendment to Hugo's proposal (1).. As I stated on the 
conference call,
I was planning to send in a New Issue with this proposal for non 
presence being equivalent to "anonymous" value. Now I do not have to.

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


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 15 February 2005 16:38:21 UTC