Re: Constraints for multicast

I think perhaps the major disconnect is here:

    "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.

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.

I don't see how we can model these cases (email, chat-room, IP
multicast, pub-sub etc.) without accounting for this basic behavior.  
Particularly in cases like email and at least some flavors of pub-sub,
there's generally no guaranteed way of determining whether you're
sending to one or 0 .. N receivers and, conversely, you don't generally
care greatly.

As far as I can tell, this work is and always has been part of properly
describing SOAP over asynchronous protocols.  In other words, it looks
to me more like old work.  I certainly don't want to rathole on it, but
I've very concerned about what the world would look like if it were
specifically put out of scope.  Would an email binding have to
explicitly forbid mailing lists, pending further work by the committee?

Fortunately, it appears that all we need to do is tweak the existing
language so as not to assume a strong coupling between sender and
receiver.  In retrospect, it seems to me that moving away from the state
machine was a very helpful step in this direction.  In terms of deltas
to the current draft, I believe there are only two changes relevant to
multicast.  The significant one is

    "The sending node MUST send the SOAP Message provided in
    http://www.w3.org/2003/05/soap/mep/OutboundMessage to the node(s)
    identified by http://www.w3.org/2003/05/soap/mep/ImmediateDestination."

This is not how several likely binding protocols work.  If I'm sending
email, I don't send to my recipients directly.  I go through a mail
server, which then sorts it out.  Once I've sent the message to the
server, I can hang up and do something else.  Likewise, if I'm jabbering
or IM-ing, I'm talking to a server and my server is talking to yours. 
As I've said, this model of "sender puts messages into the ether, each
receiver sees messages come out of the ether" appears to be central to a
significant portion net traffic.

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.  As one particular consequence, the relation between
the ImmediateDestination and the actual receiver(s) is now the binding's
concern, not the sender's.  It's up to the binding whether to support
multicast at all.  If it supports exactly one recipient per
ImmediateDestination, then it's under no obligation to deliver to more.

The second change is just proofreading: change "the receiving SOAP node"
in section 2.4 to "any receiving SOAP nodes".

Really, I still don't think we're very far apart here.  When you say:

    "It may well be that in certain cases that MEP can be used to
    implement certain forms of multicast, e.g. if that single
    destination is a multicast group."

I agree, except that I tend to think the "certain cases" will be, if not
the norm, at least a significant portion.  However ...

    That's fine. I just don't want to talk about it in the MEP.

I don't quite agree.  I believe it's necessary, and sufficient, to leave
a hook directly in the MEP, in the form of decoupling  sender from
receiver and allowing for multiple receivers.  This includes noting
that  the sender may receive both 0..N acks and 0..N naks for a given
MEP instance, but this can happen in the point-to-point case as well
(e.g., I can get multiple bounce/retry messages for a single
point-to-point email).

The rest -- e.g., buffering of multiple messages or delivering multiple
error messages -- is up to the binding.

noah_mendelsohn@us.ibm.com wrote:
> David Hill wrote:
>
>   
>> noah_mendelsohn@us.ibm.com wrote: 
>> David Hull writes:
>>
>>
>>     
>>>> Because the MEP looks like a single operation to the sender, I'm 
>>>> skeptical of a multi-MEP solution.  AFAICT, the sender would be 
>>>> participating in a composite operation consisting of 0 .. N MEPs, 
>>>> which all look identical to it.  The zero case looks especially 
>>>> troublesome.  Even if there's no one to hear it, the tree still 
>>>> falls.  Maybe I'm missing something, but this seems like it would be
>>>> a pain to word precisely, and it doesn't seem particularly close to 
>>>> the ether model.> 
>>>>         
>
>   
>>> I agree completely with your premise, but not our conclusion.  You 
>>>       
> seem to 
>   
>>> be providing a very careful analysis of why, someday somewhere there 
>>> should be at least one multicast MEP. 
>>>       
>
>   
>> Not at all.  I want it yesterday.  Multicast implementations exist 
>> right now.  IM chat room-like situations would be a third example.
>>     
>
> You misunderstand.  I'm not encouraging delay.    I'm making the case that 
> multicast is beyond the scope of what the WG has agreed to do, and I think 
> it's architecturally more properly done as a separate MEP anyway.   I do 
> think it's appropriate that the implied API (I.e. the info provided by a 
> sending app or receiving ap) be as similar as possble between one way and 
> multicast, but I think the implications for a specific binding to a 
> transport are significantly different.   I do agree that the one way MEP 
> we're creating will likely be helpful to someone drafting a multicast MEP; 
>  I don't think the W3C necessarily has to do it, and I think it's in any 
> case beyond the scope of our current effort.
>
> So, for those reasons, I don't want this simple one way effort to 
> experience feature creep and become a "one way with simple and multicast 
> modes."  If the WG had agreed to do multicast then I would have no problem 
> with us starting on it in parallel right now.  We haven't agreed to do 
> that.   The WG was in bug fix mode when the WSA team came and said: "ooh, 
> emergency, we need a one way MEP to keep our specs in sync".   XMLP said, 
> OK, we're all busy, but if it's that important we'll do it.  We're still 
> doing it a year later.  I want to do a good job on a simple one way, which 
> I think we've about done, and go back into bug fix mode, with phonecalls 
> every few months to triage issues and respond to emergencies, and an 
> occasional review to see whether something so new and important has arisen 
> that we should recharter the group for yet more work.
>
>   
>>> You correctly describe what it will 
>>> look like from sender and receiver, even correctly noting that it is 
>>>       
> in 
>   
>>> many respects similar to one way, but differs in a least one visible 
>>>       
> way, 
>   
>>> which is in the possibility of multiple or partial failures as seen 
>>>       
> from 
>   
>>> the sender.  What I don't think you've shown at all is why this should 
>>>       
> be 
>   
>>> the same MEP as the one way. 
>>>       
>
>   
>> Economy.  We've already done it, unless you see holes in the current
>> proposal.  I haven't heard it yet.  If you can demonstrate 
>> concretely what complexity this has added, I'll be glad to try to 
>> address it, but so far I've just heard the assertion that this is 
>> adding complexity.
>>     
>
> I think I made the case as well as I can.  Let's say I want to design an 
> API that will drive any binding that implements one-way.  The MEP today 
> tells me that I need a single destination address.  The proposal to allow 
> multicast suggests that the API might need to allow multiple addresses. 
> Maybe to do its job it would need to report apparent success in some of 
> the transmissions but not the others. Maybe there would be buffering 
> issues in arranging for each copy of the message to go to a different 
> destination.  I'm not saying all of these would in practice be problems in 
> each case.  I'm saying that even having to stop and think about whether 
> they might be adds delay and at least conceptual complexity.  Bottom line: 
>  I want the MEP to be written as a simple one way, with a single 
> destination property, etc.  It may well be that in certain cases that MEP 
> can be used to implement certain forms of multicast, e.g. if that single 
> distination is a multicast group.  That's fine.  I just don't want to talk 
> about it in the MEP.
>
>
>   
>>> I don't doubt that its use at sender and at 
>>> receiver will be quite similar, as seen in an application API, but an 
>>>       
> MEP 
>   
>>> is largely a specification for how to write a binding.  The binding 
>>>       
> sends 
>   
>>> the messages, and what it does for multicast, particularly on certain 
>>> transports, is quite different than for one way. 
>>> What would be an example of such a transport?   At worst, don't bind
>>> those transports and do something else.  There are certainly 
>>> transports where both the sender's and receiver's views of unicast 
>>> and multicast are substantially the same (or indeed, there is no 
>>>       
>> distinction).
>>
>> BTW, isn't the distinction between "multicast" and "unicast"?  Both 
>> are one-way, this being exactly the commonality we've captured and 
>> which I would like to keep captured.
>>     
>
> I think we're getting dangerously close to word games in putting it this 
> way.  If I have a program that sends 50 copies of a message to 50 
> destinations, is it sending them "one way"?  I think that's a bit of a 
> stretch;  it's sending them 50 ways, or at least that's an equally good 
> reading of the English.  I think you are perhaps distinguishing "with 
> responses" from "no responses", but our proposed MEP is not called "no 
> response";  it's called, and the goal we agreed to in continuing the 
> design work in the group was "one way", at least in my opinion.  If you 
> had wanted an "all cases in which there's no response MEP", then that 
> should have been discussed when we set our scope, I think.
>
>   
>> Please be more specific.  Let's try some use cases and see if this 
>> complexity pans out.
>>     
>
> I don't want to be unhelpful, but there's a time issue here.  Some of us 
> budgeted our involvment in XMLP as a maintenance activity.  Then the 
> "emergency" requirement came for a one way and we said "ok, we'll stretch 
> our schedules, but only for the minimum necessary to declare victory". 
> Then was added a long digression on whether state machines were needed and 
> how to draft what was always conceived as and is turning out to be a 
> pretty simple bit of business.  Please take no offense, but the part of 
> this that doesn't work for me is spending the time on further discussion. 
> I'm sure that's frustrating, but I just don't think multicast is what I 
> signed up to do. 
>
> If you're really uncomfortable letting it go, then I think we have to turn 
> this into a process question, which as you know is what we do in W3C when 
> these questions come up.  We need to go back to the scope of the charter 
> and what it says we've agreed to do.  If it says multicast, then fine, I 
> stand corrected (I'm on an airplane at the moment without a copy of the 
> charter.)  If it doesn't, then I would ask that while you might have hoped 
> that a one-way would provide enough of a banner under which to pursue 
> multicast, that it isn't called out in the charter, that it isn't what the 
> rest of us signed up to do, and that it's reasonable for us to ask that it 
> remains out of scope until such time as the group is rechartered with that 
> in scope. 
>
> As I've said repeatedly, I have no problem with you or anyone drafting a 
> multicast MEP, the text of would probably overlap to a significant degree 
> with one way, and posting that on behalf of Tibco or some other group for 
> public use.  I think you could have it together in a few weeks, and I 
> suspect (you should check) there would be no unresolvable copyright issues 
> in "stealing" much of the text from our one way.  As IBM representative, I 
> should say that I am not implying that IBM would or would not want to join 
> in promoting such a development.  If there is a groundswell of interest to 
> standardize it through W3C, we can to through the appropriate process to 
> see whether W3C member companies will commit the necessary resource.  If 
> I'm wrong I sincerely apologize, but I really don't recall multicast being 
> called out as a goal or success criterion for this phase of our work.  I 
> don't feel it's what I signed up to do, and I haven't budgeted the time to 
> work on it, look for holes in it, and get it right.  As I've said, even if 
> I had, I would on architectural grounds want it to be a separate MEP.
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> David Hull <dmh@tibco.com>
> 08/14/2006 05:16 PM
>  
>         To:     noah_mendelsohn@us.ibm.com
>         cc:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
>         Subject:        Re: Constraints for multicast
>
>
> noah_mendelsohn@us.ibm.com wrote: 
> David Hull writes:
>
>  
> Because the MEP looks like a single operation to the sender, I'm 
> skeptical of a multi-MEP solution.  AFAICT, the sender would be 
> participating in a composite operation consisting of 0 .. N MEPs, 
> which all look identical to it.  The zero case looks especially 
> troublesome.  Even if there's no one to hear it, the tree still 
> falls.  Maybe I'm missing something, but this seems like it would be
> a pain to word precisely, and it doesn't seem particularly close to 
> the ether model.
>  
>
> I agree completely with your premise, but not our conclusion.  You seem to 
>
> be providing a very careful analysis of why, someday somewhere there 
> should be at least one multicast MEP. 
> Not at all.  I want it yesterday.  Multicast implementations exist right 
> now.  IM chat room-like situations would be a third example.
> You correctly describe what it will 
> look like from sender and receiver, even correctly noting that it is in 
> many respects similar to one way, but differs in a least one visible way, 
> which is in the possibility of multiple or partial failures as seen from 
> the sender.  What I don't think you've shown at all is why this should be 
> the same MEP as the one way. 
> Economy.  We've already done it, unless you see holes in the current 
> proposal.  I haven't heard it yet.  If you can demonstrate concretely what 
> complexity this has added, I'll be glad to try to address it, but so far 
> I've just heard the assertion that this is adding complexity.
> I don't doubt that its use at sender and at 
> receiver will be quite similar, as seen in an application API, but an MEP 
> is largely a specification for how to write a binding.  The binding sends 
> the messages, and what it does for multicast, particularly on certain 
> transports, is quite different than for one way. 
> What would be an example of such a transport?   At worst, don't bind those 
> transports and do something else.  There are certainly transports where 
> both the sender's and receiver's views of unicast and multicast are 
> substantially the same (or indeed, there is no distinction).
>
> BTW, isn't the distinction between "multicast" and "unicast"?  Both are 
> one-way, this being exactly the commonality we've captured and which I 
> would like to keep captured.
> Furthermore, I think 
> trying to do multicast inside the one way will complicate the 
> specification of edge conditions in the one way, it will complicate 
> terminology like destination address(es) and so on.
>  
> Please be more specific.  Let's try some use cases and see if this 
> complexity pans out.
>
> I think the right design point is:  do a one way MEP.  Someone somewhere 
> does a multicast MEP (maybe more than one), and tries to make sure that 
> it's semantics are such that it will be really easy for senders and 
> receivers to support the one way and the multicast using application apis 
> that are as similar as possible.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>  
>
>
>
>