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

Noah, since you are quoting S2, the scenario document [1] is a little
more explicit on S2 than the requirements document [2]:

> Scenario S2 extends S1 to implement a fire-and-forget feature to 
> multiple SOAP Receivers and is illustrated in Figure 2. This requires
>  a mechanism to deliver the same message to multiple SOAP Receivers. 
> The delivery of the messages could be implemented using multicast 
> distribution technology if the underlying transport layer supports 
> this. An alternative implementation may use repeated applications of 
> scenario S1 with a distribution list of intended recipients.

In my opinion, this clearly shows that both approaches need to be
catered for.

Let's not open that can of worms, if possible, and focus instead on the 
other part of the issue, which is that we have somehow lost a change, 
and I essentially propose that we put it back. It's a very, very minor 
change, it was agreed in the past, it can thus be considered as an 
editorial change (as far as I'm concerned), it will take only 5 minutes 
to implement, and if we hadn't been so late in the process it's probably 
something the editors would have caught (as they did) and fixed on their 
own (as they had mandate to in the past).

Since we now have a strict no-change-before-agreement policy in place, I
reported this to some people in the WG and was encouraged to post this
as a proper issue that we can deal with in the larger WG.

I certainly understand your nervousness about possibly raising a new, 
large issue. I too would like to be done with 1.2 and not delay 
publication any more than absolutely necessary. In practice, I believe 
that the suggested changes are really trivial.

Incidently, I note that the bit of the resolution that was lost was to
an issue you had raised yourself. ;-)

Thank you,

Jean-Jacques.

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


noah_mendelsohn@us.ibm.com wrote:

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

Received on Tuesday, 17 June 2003 03:56:08 UTC