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

Hugo Haas wrote:

> 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.
Does "a reply" mean an "application level response to the message sent 
using ws-addressing"?

This is important, since some other soap header based
protocols can have their own orthogonal soap header reply mechanisms 
(e.g., for the
ws-Reliability callback reply pattern, a protocol reply soap header is 
sent to a callback address contained  in a ws-Reliability specified soap 
header element sent with the request message ).

I would like to be sure that such a case is not considered a "reply 
using ws-addressing".

Tom Rutt

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

Tom Rutt	email:;
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 14 February 2005 19:23:34 UTC