W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

i050: Misalignment of treatment of reply messages and fault messages

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 7 Mar 2005 10:46:00 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A506C16B29@RED-MSG-30.redmond.corp.microsoft.com>
To: <public-ws-addressing@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT