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."

Received on Monday, 7 March 2005 18:46:03 UTC