- From: David Hull <dmh@tibco.com>
- Date: Wed, 21 Mar 2007 12:17:17 -0400
- To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
- Message-ID: <46015A8D.1060202@tibco.com>
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 Wednesday, 21 March 2007 16:17:44 UTC