Re: Constraints for multicast

Anish Karmarkar wrote:
> I meant acknowledging it.
>
> For example, the only difference between IP multicast and a IP unicast
> (from a sender's viewpoint) is that IP multicast address is a separate
> class D address (range: 224.0.0.0 - 239.255.255.255).
Right.  The whole point in taking this on is that there's very little
difference from the point of view of the sender or from the point of
view of any particular receiver.  It's only when you have to talk about
the correlation between "sender sends" and "receiver(s) receive" that
there's any cause to mention cardinality.

To me, the important part that we're capturing is that a binding MUST
say "this is what you do to send" and "this is what you do when a
message comes in".  That information should be independent of exactly
how sending events are correlated with receiving events.  The email
binding sketch I sent basically says that, and also "senders are
connected to receivers via email" and "which of course means that there
can be multiple receivers for a given address".

IMO it's the message mapping information -- how the properties manifest
as parts of an email message -- that's the real value added.  Arguably,
if you're using email for transport you already know how email works. 
What you don't know is the standard way to put SOAP into email and get
it back out again.

My objection to unicast only is that the mapping information is common
to both, and I don't want to have two separate MEPs saying "this is how
you put SOAP in a message sent to a single address" and "this is how you
put SOAP in a message sent to multiple destinations", when it's the same
in both cases.  Particularly if you can't tell the difference anyway.


>
> -Anish
> -- 
>
> David Hull wrote:
>> 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/>
>>>
>>
>

Received on Wednesday, 30 August 2006 18:54:57 UTC