Re: i050: Misalignment of treatment of reply messages and fault messages

Jonathan,
  Can we change "unconstrained by this specification" to something that
indicates its the equivalent of using the anonymous URI?  I believe that 
clients will
expect the response to not only come back on the http response flow (or 
whatever is
defined by the binding) but that it will also include the appropriate WSA 
headers.
Leaving it as "unconstrained" means they may or may not appear on the 
response
and I think it would be better to be explicit (and to include them).
-Dug




"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org
03/07/2005 01:46 PM

To
<public-ws-addressing@w3.org>
cc

Subject
i050: Misalignment of treatment of reply messages and fault messages







Per my AI to propose concrete text for option 3 (and I recall that was
as modified by the FaultTo -> ReplyTo amendment even though the minutes
aren't very clear), I propose we:

- explain that ReplyTo and FaultTo are different, and therefore don't
act precisely the same way,

- add an explicit rule that faults are sent to FaultTo, when present,
otherwise ReplyTo, when present.

Concrete text follows:

Add the following note, perhaps after the description of [fault
endpoint]:

  "Note that faults and replies are different in terms of client
  expectation - replies are anticipated by a client while faults under
  normal circumstances are not.  This difference is manifest in the
  [reply endpoint] property being mandatory when the client expects a
  reply, while the wsa:FaultTo is optional."

[FWIW, I don't think this text is really necessary, I'd be happy to
simply drop it.]

Section 3.2 bullet 1b:
  "Otherwise, if the reply is a fault message and the incoming message's
  [fault endpoint] message addressing property is not empty, select the
  EPR from this property. If the [fault endpoint] property is empty, the
  behavior of the recipient of the incoming message is unconstrained by
  this specification."
-->
  "Otherwise, if the reply is a fault message and the incoming message's
  [fault endpoint] message addressing property is not empty, select the
  EPR from this property. If the [fault endpoint] property is empty, 
  select the EPR from the [reply endpoint] message addressing property,
  if it is not empty. If the [reply endpoint] message addressing 
  property is empty, the behavior of the recipient of the incoming 
  message is unconstrained by this specification."