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

Proposed text for

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

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