Re: New PR issue: one or more ultimate receiver?

Jean-Jacques Moreau writes:

>> I don't think the issue is about designing a 
>> new multicast MEP right now, nor about reusing 
>> the existing Request-Response MEP for doing 
>> multicast; it is whether one can indeed 
>> design a multicast MEP with the current framework, 
>> without limiting the design range.

Actually, I would respectfully disagree a bit with your characterization 
of where we stand.  I think that in attempting to go to Recommendation 
status the question is whether we have reasonably met our requirements. 
Our requirements say [1]:

R502 
The specification developed by the Working Group must support either 
directly or via well defined extension mechanisms different messaging 
patterns and scenarios. The specification will directly support One-way 
and Request-response patterns as part of permanently and intermittently 
connected scenarios. The specification will not preclude the development 
of other patterns at either the application or transport layers. Examples 
of such patterns may include publish-subscribe or multicast delivery. All 
patterns and scenarios will be described by relevant usage scenarios (see 
6. Usage Scenarios).

There is also a usage scenario:

S2 Fire-and-forget to multiple receivers 
A sender wishes to send unacknowledged messages to a set of receivers 
(e.g. send a stock price update every 15 minutes)

Note:

S2 Originates from splitting the ebXML use case 1.1 into 2 scenarios (S1 
and S2). Note that S2 may be decomposed into Multiple instances of S1 
under the control of some "higher-level" process such as multicast or 
publish/subscribe.

I don't see anything in this that requires support for multicast "without 
limiting the design range".  I think the requirement obligates us to 
provide an MEP framework that offers good promise of supporting at least 
some intersting flavors of pub/sub and/or multicast.  I believe my note 
makes the case that we have done so.  The usage scenario suggests that we 
should be able to invent an MEP that covers a "fire n' forget" to multiple 
receivers.  I believe it's self-evident that we can do at least several 
flavors of that. 

Again I would note that, as far as I'm aware, no comments were raised by 
implementors on any related issues during the CR phase.  In short, I think 
we have easily met our requirements in this area, and that discussion of 
possible additional specific desiderata relating to multicast should not 
in any way delay our progress toward recommendation.  Once we go to 
recommendation, we can consider whether there are indeed variants of 
multicast that we do not handle as well as we might (and I'm not sure 
there are), and whether those should or should not be considered as 
requirements for possible future versions of SOAP (if any).  Thank you!

Noah

[1] http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626#N443
[2] http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626#N2690

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