W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2007

Re: Proposed text for WSDL issue 1

From: David Hull <dmh@tibco.com>
Date: Thu, 22 Mar 2007 11:23:17 -0400
Message-ID: <46029F65.8080202@tibco.com>
To: noah_mendelsohn@us.ibm.com
CC: "xml-dist-app@w3.org" <xml-dist-app@w3.org>, xml-dist-app-request@w3.org
noah_mendelsohn@us.ibm.com wrote:
> I'm sorry I missed the call today.   Can someone please update me where we 
> are on the multicast question.  The following implies that one-way is 
> multicast after all.  I vaguely recall that we were looking at two 
> variants with slight differences.  Can someone remind me what we have and 
> haven't agreed wrt that?  The attached seems to assume that one-way 
> includes multicast.  Thank you.
>   
My understanding is that we put out a draft with multicast (as indicated
by the text being replaced), along with a prominent note asking for
feedback.  The only feedback we've received to the comments list is from
the WSDL group, and none of their comments takes issue with multicast.

On the call, we opted for proposal 1, with the amendment that we say
that the /envelope/ in the message properties  SHOULD be identical, as
opposed to the entire property itself.  This change deliberately avoids
touching anything to do with multicast -- it's equally valid for
unicast, except that you would want to rephrase "each successful
receiver".  Proposal 2 was also intended to leave multicast alone, but
to make the role of properties more explicit.  As has often been the
case, the underlying issue is independent of multicast.

In short, the draft was multicast, the current version is still
multicast, just more sharply defined, we had asked for comments on
multicast and no one commented.
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> David Hull <dmh@tibco.com>
> Sent by: xml-dist-app-request@w3.org
> 03/21/2007 12:17 PM
>  
>         To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Proposed text for
>
>
> Replace the sentence in section 2.2, "The scope of a one-way MEP is 
> limited to transmission of (nearly) identical messages from one sending 
> node to zero or more receiving SOAP node(s); typically, in the case of 
> multiple receivers, the messages differ only in their destinations."
>
> With either
>
> Proposal 1 (minimal fix)
> "The scope of a one-way MEP instance is limited to transmission of 
> messages from one sending node to zero or more receiving SOAP node(s). The 
> ImmediateSender and ImmediateDestination properties may differ among 
> nodes.  The InboundMessage property at each successful receiver SHOULD be 
> identical to the OutboundMessage at the sender."
> Proposal 2 (a bit more explicit)
> "An instance of the one-way MEP consists of
> A single sending node populating the OutboundMessage, ImmediateSender and 
> ImmediateDestination properties described in section 2.3
> Zero or more receiving nodes populating the InboundMessage, 
> ImmediateSender and ImmediateDestination properties and processing the 
> InboundMessage as described below.
> Any fault processing as described below
> The ImmediateSender and ImmediateDestination properties may differ among 
> nodes.  The InboundMessage property at each successful receiver SHOULD be 
> identical to the OutboundMessage at the sender."
> In either proposal, we might also change "A receiving node MUST determine 
> ... " to "Each receiving node MUST determine ..." in paragraph 3 of the 
> section, emphasizing that each receiver has its own notion of success.
>
> Note that we do not currently require that a receiving node that 
> determines success MUST populate InboundMessage with the sender's 
> identical OutboundMessage.  A message could be silently corrupted or might 
> be altered for other reasons.  I believe this is the right call, and that 
> implementations are free to promise better QoS on top of this (e.g., 
> "Barring catastrophe, receivers will either receive an identical message 
> or fault")
>
>   
Received on Thursday, 22 March 2007 15:38:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:24 GMT