Re: Constraints for multicast

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?

If I send the same email to distApp, I tend not to get such bounces in the 
course of sending (though I may of course get bounce replies, but we both 
agree those are beyond the scope of either form one one-way MEP).

Sometimes the natural interface to a multicast is identical to the natural 
interface for a unicast; sometimes not.  In the case above, the interface 
to the multicast naturally included a "partially failure to send", "OK to 
send to part of the mulitcast group, etc."  That's why my preference is to 
not advertise anything to do with multicast in specing this MEP.  If your 
particular flavor of multicast is so similar to one way that it fits, then 
fine.  You can always model this as "sure I used that one-way MEP for my 
multicast -- what I really did was send to one destination (the list) one 
message (as sent);  it's an artifact of my implementation that we down 
under the cover bits fanned out on what seemed to be multiple paths to 
reach the distributed implementation of that one logical destination, I.e. 
the multicast group.  I don't mind anyone using the MEP with multicast, I 
just don't want to head down the slippery slope of implying that we are 
going to undertake to add things to the MEP as necessary to make it work 
with this or that flavor of multicast.

> What I'm trying to capture is that, in a number of significant 
> realizations, a single ImmediateDestination can denote 0 .. N 
> receiving nodes, in a way that is of interest to the binding.  For 
> example, it doesn't matter whether I joined xml-dist-app by sending 
> a request to xml-dist-app-owner, bribing someone at W3C, hacking 
> into the W3C servers, or even subscribing my own mailing list as a 
> member of xml-dist-app.  Neither does it matter exactly how the mail
> infrastructure causes messages to appear in people's mailboxes. 
> What matters is that if I send a SOAP message to a given address, 0 
> .. N SOAP nodes will, in normal operation, execute the SOAP 
> processing model on what I sent.

If you look at it that way, I strongly feel that it's a different MEP.  If 
you want to view the multicast group as one distributed/replicated 
receiving node, that's up to you, but you'll have to deal with the fact 
that you're stretching things.  Those N receivers may have different 
notions of whether faults occurred, for example, and while the MEP won't 
cause the sender to know, and omniscient observer will.

In fact this convinces me more strongly that one way is not multicast, 
because you've acknowledged that N SOAP messages are being sent and the 
SOAP processing model is being invoked N-e times (where e is the number of 
failures to transmit), and the whole reason we invented MEPs was to be 
able to tell how that's different from a single message with a single SOAP 
processing invocation (or failure). 

I'm not saying we couldn't have a multicast MEP with unicast as a 
degenerate case.   I'm saying:

a) I'd call it multicast, not one way
b) I think we'd really loose something by not having a clear simple 
separate MEP for the 90% case.

> However, if we change "The sending node MUST send" to something more
> like "The binding MUST manage delivery of", we're much closer to 
> what's really happening. 

I'm curious as to whether others in the WG consider that a useful 
instruction as that main point of conformance for the sender.

Anyway, the TAG on it's mailing list guidelines has a suggestion which I 
think is a good one, which is basically that when a conversation like this 
goes back and forth about 3 times it's about time to stop.  I'm not saying 
drop the issue, but stop batting emails back and forth.  I think readers 
of this thread will well understand both of our concerns.  We've both had 
a chance to set them out in some detail.  I would suggest that our chair 
and the workgroup collectively consider our exchange and decide on:

a) whether enabling this MEP for multicast is the right course 
technically, even assuming that the spec. work involved is as 
straightforward as you suggest (my own intuition is that the immediate 
changes to the spec would be indeed small, the philosphical change very 
significant and in my view undesireable, and the risk of scope creep 
moderate but real).
b) if the answer to the above is "yes in principle", then the group should 
quickly estimate what work and risk will be involved, and confirm that not 
only is this desirable in principle, but that the cost/benefit is positive 
and that we want to take the time to attempt the appropriate redrafting.
c) if the answer to b is "yes", then we should go ahead and do it.

As noted, I am fairly strongly opposed to answering "yes" to (a), and so 
can personally avoid most of the need to look at (b).  That said, if a 
preponderance of the workgroup agrees with you that this should be done, 
and if their analysis at the (b) level is that the cost/benefit is 
favorable, I would not stand in the way.

In short, I propose that we stop now what has been essentially a two-way 
exchange between us, and ask the group what they'd like to do.   I think 
we've each set out pretty clearly the facts as we see them.  Thanks!

Noah


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Thursday, 24 August 2006 01:16:28 UTC