Re: Constraints for multicast

I'm not entirely clear what "modeling multicast explicitly" means.

If it means acknowledging that multicast can happen, i.e., that a single
act of sending a message can result in multiple acts of receiving the
same message, then I don't see how we can avoid this and still produce
useful bindings for several transports of interest.  Since it appears by
example that we /can/ produce a useful binding with such acknowledgment
(in the English sense, not the protocol geek sense!) in the MEP, and no
one has given anything concrete about how we might proceed without it,
I'd say this point is pretty clear-cut by now.

If it means trying to talk about things like how one might join a
multicast group, or how a binding might do fan-out or use network-level
broadcast or whatever, then of course not.  That would complicate the
architecture to no end and for no gain, and I would be strongly against it.

Anish Karmarkar wrote:
> noah_mendelsohn@us.ibm.com wrote:
>> David Hull writes:
>>
>>> "The proposal to allow multicast suggests that the API might need to
>>> allow multiple addresses."  This is certainly not the intent of the
>>> proposed text.  To take an example, if I send email to {dmh@tibco.
>>> com, noah_mendelsohn@us.ibm.com}, that would be two instances of the
>>> MEP.  If I send email to {xml-dist-app@w3.org}, that would be one
>>> instance, just as if I sent to {dmh@tibco.com}.  In other words,
>>> there is exactly one ImmediateDestination per MEP instance, just as
>>> the table says.
>>
>> When I send an email to a local distribution list (e.g. to:
>> xml-interest or some such) it's not uncommon for my mailer to pop up
>> a warning in the spirit of the following, one I would never see in
>> sending to an individual:
>>
>>         Warning: email addresses BobSmith, MaryJones, TommySlim not
>> found, continue sending to the other 53 users on this list?
>>
>
> Isn't this a binding specific error?
> One could get a simliar error when sending an email to an address
> which is not a mailing list (without the question about 'continue
> sending'). Since we are really talking about fire-and-forget, I don't
> think these errors or warnings have a relevance at the MEP-level.
>
> I do share Noah's concern about feature-creep and finishing up our
> one-way MEP work. I would prefer that our one-way MEP allow folks to
> use it for multicast (our MEP spec should not prevent it), but we
> shouldn't go into modeling it explicitly.
>
> -Anish
> -- 
>
>
> <snip/>
>