RE: Issue 6 (Message Property Optionality)

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?

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

Under the status quo:
1. when wsa:From is present (optional) the information conveyed is:
   a) where the message originated.

2. when wsa:ReplyTo is present the information is conveyed is:
   a) reply expected, and 
   b) where to send the reply.

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

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

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

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

Received on Friday, 7 January 2005 22:36:14 UTC