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/

Received on Tuesday, 15 February 2005 15:14:52 UTC