Re: Issue i044: Definition of the rules to reply to a message in Core 3.2

Because the discussion that followed my second proposal, I thought it
would be useful to recap the issues that i044 exhibited.

First, here is my second proposal with Marc's fix about the nature of
[message id], and "undefined" being changed into "unconstrained by
this specification" (more below about that). I also noted that my
proposed rules were missing something: if a reply is expected and no
reply-to is specified, then the processor must fault; I have fixed
this.

----8<--

The reply to an incoming message using WS-Addressing is constructed as
follows.

1. Select the appropriate EPR

If the reply is a normal message, select the EPR from the incoming message's
[reply endpoint] message addressing property. If none is present, the
processor MUST fault.

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.

2. Populate the reply message's message addressing properties

The following message addressing properties are populated as follows:
- [destination]: this property takes the value of the selected EPR's
  [address] property
- [relationship]: a new pair of URIs is added to this value as
  follows; the relationship type is the predefined reply URI
  http://www.w3.org/@@@@/@@/addressing/reply and the related message's
  identifier is the [message id] property value from the message being
  replied to; other relationships MAY be expressed in this property
- [reference parameters]: this property takes the value of the
  selected EPR's [reference parameters] property

-->8----

The discussion around this proposal (which prompted the rewording of
"undefined") is about the following: in the case of faults and the
absence of [fault endpoint], our spec doesn't define any particular
behavior; IOW, a processor does whatever it would do if addressing
wasn't present (e.g. send a fault back to the sender on an HTTP
response for a request-response over HTTP).

People have expressed discomfort (which I share) as section 3 presents
faults as replies, and normal replies are treated very differently: a
[reply endpoint] MAP is required if a reply is expected, i.e. if
Addressing was in use, and no [reply endpoint] was specified, a fault
would be raised.

At this point, I think that we need to have a discussion on the call
about how the Group feels about it.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/