Re: Proposed text for

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.

--------------------------------------
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 Wednesday, 21 March 2007 22:31:46 UTC