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

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

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

Marc.

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:01 GMT