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

See below:

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Hugo Haas
> Sent: Tuesday, February 01, 2005 7:17 AM
> To: public-ws-addressing@w3.org
> Subject: Issue i044: Definition of the rules to reply to a message in
> Core 3.2
> 
> Based on the discussion on yesterday's call, the proposal I made for
> issue i044[4] needs to be expressed in terms of message addressing
> properties.
> 
> The previous version's last step was wrongly talking about SOAP
> headers. As Marc pointed out, we do not need to talk about SOAP
> serialization in the core, as the part about reference parameters is
> covered in [3]:
> 
> * Hugo Haas <hugo@w3.org> [2005-01-16 19:27-0500]
> > -=- Proposal -=-
> >
> > Spell out rules for replying to a message, which I believe to be:
> > - select reply endpoint, fault, or source EPR, depending on the type
> >  of message being replied and the information found in the first
> >  message
> > - use the EPR's [address] property as the [destination] MAP
> > - use the [message id] MAP as the [relationthip] URI with the right
> >  relationship type
> > - echo the EPR's [referance properties] and [reference parameters]
> as
> >  SOAP headers
> 
> 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.

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

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

> - [reference parameters]: this property takes the value of the
>   selected EPR's [reference parameters] property
>
> -->8----
> 
> Note that, in order to do that cleanly, I have used a [reference
> parameters] message addressing property which currently does not
> exist; introducing one is something which also has benefits in the
> context of issue i021, as per [1] and [2]. This is a proposed change
> for section 3.
> 
> Cheers,
> 
> Hugo
> 
>   1. http://lists.w3.org/Archives/Public/public-ws-
> addressing/2004Nov/0529.html
>   2. http://lists.w3.org/Archives/Public/public-ws-
> addressing/2004Dec/0067.html
>   3. http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-
> soap.html#_Toc77464317
>   4. http://www.w3.org/2002/ws/addr/wd-issues/#i044
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Friday, 4 February 2005 19:09:35 UTC