Clunkiness

Noah's proposed change for dealing with multicast destinations involves
describing the ImmediateDestination thus:

    "The identifier of the immediate destination of an outbound message. (NOTE: the URI supplied MAY be the identifier of a single destination SOAP node, or MAY be the identifier of a multicast group, which itself consists of zero or more destination nodes.   Whether multicast is supported is binding-dependent.  This MEP specification provides no standard means for representing a multicast group, except to require that the group as a whole be designated by a URI.)"

I agree this is clunky.  The first sentence (taken from the current
draft text) is tautological and the rest complex.  I disagree it's
necessary to describing multicast.  What's necessary is to align the
description with the rest of the document:

    Identifies, in a binding specific way, the SOAP node(s) meant to
    receive the message.

I agree that it's worth noting that some bindings may be strictly
unicast (which ones were those again?).  That note should go at the top,
either right before or after "Implementations MAY choose to support
multiple MEPs at the same time." in the first paragraph of 2.2:

    Implementations MAY choose to limit the number of receivers to
    exactly one.

I don't see any need to mention that we provide no standard means for
representing a multicast group.  We require no standard means of
representing a destination at all.  The rest of the note is a clear
consequence of the two statements above.  These statements, or at least
the first, have been on the table for a while now.  The concept of
mapping an ImmediateDestination to zero or more receivers has been on
the table somewhat longer yet.  This is not an endless stream of minor
tweaks.  It's a finite amount of carrying through a suggestion already made.

If we accept that there may be zero or more receivers for a given
message -- or if you prefer, that the /event /of receipt may happen zero
or more times for given message /data/ -- then as far as I can tell the
special casing pretty much goes away.  It's trying to maintain a strong
distinction between unicast and multicast that makes things clunky. 
Given that implementations don't tend to distinguish, except in that
some may offer syntactic means to tell the difference between a unicast
or multicast /address/, I don't see why we should.

What I find extremely clunky, though, is the notion that we should carry
this distinction through all the way to having separate MEPs for the two
cases -- or rather the one case and a particular subcase.  Besides our
having to write and maintain two largely identical MEPs, bindings that
support both will then have to point this out.  I don't see why.  It
seems enough for a binding to have a single sentence at the top saying
"this binding limits the number of receivers to exactly one." or words
to that effect.