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

Re: Issue 6 (Message Property Optionality)

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Mon, 10 Jan 2005 14:16:52 -0500
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: public-ws-addressing@w3.org
Message-id: <2EEBCE5C-633C-11D9-99AE-000A95BC8D92@Sun.COM>

On Jan 7, 2005, at 5:36 PM, Jonathan Marsh wrote:

> I don't understand the motivation for parts ii and iii of this 
> proposal.
> The justification includes "without loss of information" but I don't 
> see
> this as true.  Can you comment on my analysis?
Sure, see below. Note that this proposal was made before we agreed to 
drop the text that allows replies to be sent to the [source endpoint] 
when a [reply endpoint] is not provided, so we've already removed some 
of the confusion and duplication that my proposal was trying to 
address. [source endpoint] is now unused in any of the MEPs we define.

> Under your proposal:
> 1. when wsa:From is present (required when a reply is expected) the
>    information conveyed is:
>    a) reply expected,
>    b) where to send the reply,
>    c) reply destination is the same as the source, and therefore
>    d) where the message originated.
> 2. when wsa:ReplyTo is present (required when a reply goes somewhere
>    other than the source), the information conveyed is:
>    a) reply expected,
>    b) where to send the reply, and
>    c) reply destination is not the same as the source.
> 3. when wsa:From and wsa:Reply to are both present, the information
>    content is:
>    a) reply expected,
>    b) where to send the reply (wsa:ReplyTo),
>    c) where the message originated, and
>    d) whether the source and reply endpoints are the same
>       (compare wsa:From and wsa:ReplyTo?).
We seem to have settled on requiring [reply endpoint] whenever a reply 
is expected, [source endpoint] isn't used in any of our MEPs though I 
agree it could be used to designate the origin of a message, its just 
that origin of a message play no part in the MEPs.

> Under the status quo:
> 1. when wsa:From is present (optional) the information conveyed is:
>    a) where the message originated.
Yes, but as stated above message origin isn't relevant to the MEPs we 

> 2. when wsa:ReplyTo is present the information is conveyed is:
>    a) reply expected, and
>    b) where to send the reply.
b) yes, but a) is incorrect. You have to include [reply endpoint] if 
you expect a reply, but just because you include it doesn't mean you 
expect a reply. I.e. its OK to include it in a message that doesn't 
expect a reply. E.g. [reply endpoint] is optional in the one-way MEP.

> 3. when wsa:From and wsa:ReplyTo are both present, the information
>    conveyed is a combination of the above information, plus:
>    e) whether the source and reply endpoints are the same
>       (compare wsa:ReplyTo and wsa:From).

> The differences between the proposal and the status quo from an
> information content perspective appear to be:
> - The status quo allows the source of the message to be communicated
> orthogonally with whether a reply is expected.

Not really, see above.

>   The new proposal
> doesn't.  If source information isn't important outside the context of
> formulating a reply message, a cleaner proposal would be to drop
> wsa:From completely, perhaps replacing it with an attribute on
> wsa:ReplyTo asserting that the replyTo address is the same as the
> destination.  I believe wsa:From is useful (and should be orthogonal) 
> to
> construction of replies.
That seems to be the direction we've adopted.

> - Your proposal makes sure one is always able to determine whether the
> reply goes back to the requester.  It's not clear why this is useful
> information.
I wonder how many replies are really required to go somewhere other 
than the originator ?

> - In addition, it's not clear whether source information is always
> available (hence it's optionality).  That is, it seems reasonable to
> send a message, requesting a reply to a different destination, when the
> requester either chooses not to disclose its source address, or is
> unable to disclose its source address.  For example, the endpoint
> doesn't actually know its address in a form that can be communicated to
> the service, or the address is temporary and immediately disappears
> after the request is made.
> In sum, your proposal for ii and iii looks a lot more complicated to me
> than the status quo and changes the expressiveness of the language in
> ways that are unmotivated by (indeed in conflict with) the 
> justification
> you provide.
I think the two options really have the same level of expressivity 
(your assertion that presence of [reply endpoint] indicates a reply is 
expected is incorrect), my proposal was grounded on removing something 
for which a default existed but since we dropped that semantic [reply 
endpoint] falling back to [source endpoint] then I'm happy to drop that 
part of my proposal.


>> -----Original Message-----
>> From: public-ws-addressing-request@w3.org [mailto:public-ws-
>> addressing-request@w3.org] On Behalf Of Marc Hadley
>> Sent: Monday, November 08, 2004 9:46 AM
>> To: public-ws-addressing@w3.org
>> Subject: Issue 6 (Message Property Optionality)
>> Description:
>>  From the issues list: "In some situations, information is required,
>> when it could be optional; e.g., the To address that's also in the
>> transport binding. Could it be made optional ?"
>> Target:
>> Core, SOAP Binding
>> Justification:
>> The specification currently mandates the serialization of some message
>> addressing properties as SOAP headers in messages when they could be
>> omitted without loss of information or is less than clear about their
>> optionality:
>> (i) Anonymous address:
>> <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/
>> anonymous</wsa:To>
>> (ii) <wsa:ReplyTo> - optional, "MUST be present if a reply is
>> expected", "If the [reply endpoint] is absent, the contents of the
>> [source endpoint] may be used to formulate a message to the source."
>> I.e. it must be present, but if not use <wsa:From> instead.
>> (iii) <wsa:From> - optional, can be used to provide a default for
>> ReplyTo and FaultTo.
>> (iv) <was:Action> is already being discussed elsewhere.
>> Proposal:
>> (i) Omission of a <wsa:To> header block is semantically equivalent to
>> its inclusion with a value of
>> "http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous", a
>> role of ultimate recipient (or maybe next depending on outcome of
>> issue
>> 7) and mustUnderstand="true" .
>> (ii), (iii) <wsa:From> required if a reply is expected, <wsa:ReplyTo>
>> only required if a reply is to be sent to an endpoint other than the
>> one in <wsa:From>.
>> Marc.
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> Web Technologies and Standards, Sun Microsystems.
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Monday, 10 January 2005 19:16:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC