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

* Jonathan Marsh <jmarsh@microsoft.com> [2005-02-04 11:09-0800]
> > Here's a revised proposal for the rules of a reply message. It is more
> > detailed. The proposed text is for section 3.2:
> > 
> > ----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 and the incoming message's [reply
> > endpoint] message addressing property is not empty, select the EPR
> > from this property.
> > 
> > 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.
> > 
> > Otherwise, if incoming message's [source endpoint] message addressing
> > property is not empty, select the EPR from this property.
> 
> I assume you are trying to faithfully recreate the rules from the spec
> as is, rather than modify those rules.  If so, where in the spec does it
> say that you MUST use [source endpoint] for both replies if there is one
> and there is no [reply endpoint]?  And similarly for faults/[fault
> endpoint]?  I thought we removed text from both [reply endpoint] and
> [fault endpoint] that indicated that one MAY do this, on the grounds
> that the MAY didn't constrain anything.
> 
> If we want to change this behavior (reopen that issue?) then we should
> consider it separately from the rest of your rules, which otherwise look
> OK to me.  The newly added clauses look reasonable to me but I'd like to
> think on them a bit more.

You are right. The intent was not to invent new rules, and I got
confused by the following in section 3, which actually isn't a rule:

  "Request Reply" is a common interaction pattern that consists of an
  initial message sent by a source endpoint (the request) and a
  subsequent message sent from the destination of the request back to
  the source (the reply).

We did clearly specify the following for replies:

  If a reply is expected, a message MUST contain a [reply endpoint].

So the rules are simpler than I thought for replies.

For faults, we did indeed clarify, with the resolution of issue 29[3],
to leave it undefined when no [fault endpoint] was present.

> > Otherwise, select an EPR whose [address] property is the anonymous
> > endpoint URI, http://www.w3.org/@@@@/@@/addressing/role/anonymous.
> 
> The same concern applies here to.  In addition, it could be clearer what
> "an EPR whose [address] property is the anonymous endpoint" means.  Are
> there any constraints on what the rest of this EPR should look like?
> E.g., may I invent some [reference parameters]?

Based on the correction you made above, as well as the resolution of
issue 29, this text does not need to be there anymore.

> > 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; the
> >   selected EPR's [message id] property value is used as the related
> >   message; the appropriate relationship type is associated with it
> 
> Could this be a little tighter?  The spec says a reply message (which I
> infer includes faults) must use the predefined reply relationship type.

You are correct, and a fault being sent as the reply to an incoming
message probably deserves the same relationship URI.

We should probably specify that other relationships may be expressed.

> > - [reference parameters]: this property takes the value of the
> >   selected EPR's [reference parameters] property
> >
> > -->8----

Here's a revised proposal, which reflects the resolution of issue 29
and fixes the relationship mistake:

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

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

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 selected EPR's [message id] property value; other
  relationships MAY be expressed in this property
- [reference parameters]: this property takes the value of the
  selected EPR's [reference parameters] property

-->8----

Cheers,

Hugo

  3. http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item20
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/