RE: Issue 6 (Message Property Optionality)

Thanks for the reply.  You're right that I overstated the information
carried by ReplyTo.  My concern was that a user would find it
non-intuitive to put in wsa:From sometimes and wsa:ReplyTo other times
in order to tell where to send the reply.  I like keeping these as
orthogonal as possible.  But if you're dropping parts ii and iii of your
proposal those concerns are moot.

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM]
> Sent: Monday, January 10, 2005 11:17 AM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: Issue 6 (Message Property Optionality)
> 
> 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 20:00:10 UTC