Suporting multicast with an "exactly once" MEP

Re-reading Noah's changes, I noticed something I'd missed the first
couple of times around:

    In the absence of failure in the underlying protocol, this MEP
    consists of zero or more SOAP messages. 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.

First, note that this re-writing of destination can also happen in any
unicast protocol that forwards, and that it need not happen at all in a
multicast protocol.  As always the root cause is decoupling, not multicast.

Decoupled messaging may be broken down into two interactions: Sender
gives a message to the transport ("into the ether"), and transport gives
message to receiver ("out of the ether"), with the second part happening
zero or more times in general.  Each of these, however, is a simple
one-way interaction with a single sender and a single receiver.

The transport may thus be seen as a pseudo-intermediary that
participates in a unicast one-way MEP instance with the sender and with
each receiver separately.  It may also choose to re-write the
destination of the message sent.  I say "pseudo-intermediary" because
this scheme is probably not kosher with respect to the SOAP model of a
single path from sender to receiver.  Strictly speaking we (probably)
have N+1 SOAP messages sent: One from sender to transport, N from
transport to receiver.

(Alternatively we could define N message paths, each originating at the
sender and terminating at a receiver and all going through a single
intermediary which may rewrite the destination, but I'm leery of this. 
The sender should see only one path.  I'm particularly uneasy with the
case of zero receivers.)

As I've said, I'm not sure that this solution fits well with the SOAP
messaging model (frankly, that's been a recurring concern), and in
particular how it interacts with intermediaries.  It would seem to
require that all intermediaries come between the sender and the
transport or the transport and the receiver.  This might not be a
problem.  E.g., an encrypting intermediary would always go between
sender and transport, and conversely for decryption.  I suppose it all
depends on what we're doing with intermediaries.  If there's a solid
case for sending /to/ an intermediary /through/ a decoupled transport,
we may need to re-think.

Other than that, how does it fit the basic constraints I mentioned earlier?

   1. Actual implementations do it.  If I publish a message, or send it
      to a mailing list, or send a broadcast or IP multicast packet,
      multicast will happen.
   2. Multicast looks like a single operation to the sender.
   3. Multicast looks like a single operation to /each/ receiver.
   4. The sender and all receivers are participating in the same
      operation, particularly for the purposes of logging and error
      reporting.

We account for (1) by treating the transport as a forwarding agent. 
This seems quite natural.  In many cases (e.g. email, IM) the connection
between sender and receiver and a forwarding agent is explicit.  In
others one can at least make a plausible case for it.

We account for (2) by treating the act of sending as a MEP instance
between the sender and the transport.

We account for (3) by treating the act of receiving as a MEP instance
between the transport and the receiver.

We don't seem to account for (4) directly, but (4) might not be a valid
constraint anyway.  In a decoupled world, senders and receivers may know
nothing about each other.  If they do, it's either because the transport
provides means for them to do so, or because there's something in the
messages themselves.  Either one is compatible with the model given. 
For that matter, I don't think the current text really addresses this
explicitly either, nor should it.

What we've done here is to give up on modeling the sender/receiver
interaction as a single MEP.  I hasten to point out that this is
inherent in decoupling and not peculiar to multicast.  If I send you
(and you only) email, I don't wait until you receive it.  I send it and
I'm done.  Later, you pick it up.  AFAICT, it makes much more sense to
model this as two interactions than as one two-part interaction with an
indefinite (and possibly infinite) wait between parts.

How does this affect bindings?  I'm not sure it does, at least not
much.  The core of a binding is the mapping between bundles of
properties and transport-level messages, and that remains intact. 
Separating sending and receiving into different MEPs leaves room for the
binding to describe things like the re-writing of the destination in
some (but not all) transports.  Since this is transport dependent, it
has to be the binding that discusses this.

Note that bindings to the existing text can talk about this, with or
without Noah's amendment, since the sender and receiver have separate
copies of the properties.  The alternate I've proposed above just seems
to provide a more natural place to do so.