- From: David Hull <dmh@tibco.com>
- Date: Thu, 22 Mar 2007 11:23:17 -0400
- To: noah_mendelsohn@us.ibm.com
- CC: "xml-dist-app@w3.org" <xml-dist-app@w3.org>, xml-dist-app-request@w3.org
- Message-ID: <46029F65.8080202@tibco.com>
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 UTC