Re: [wsrm] Proposed resolutions for ChrisF issues 3,4,6,8,10

[Doug Bunting <Doug.Bunting@Sun.COM>]

Jacques,

Good additions.

For (4), I do not understand a MAY / MUST for stopping the "resend loop" 
after receiving a Fault without a MAY / MUST for stopping after receiving 
an acknowledgement.  In both cases, I would prefer MUST since to do 
otherwise just wastes RMP time.  This would also be one of those nice 
externally observable requirements.

For (5), I am not sure what you are suggesting but suspect your comments 
work with the proposal in Tom's "1,2,24,5,7,9,16,19" email.

I have one further comment below.

thanx,
	doug

On 15-Jul-04 20:45, Jacques Durand wrote:

...

> 10) line 265/8 reads: ... getting perilously close to implementation detail
> "An RMP which supports both Submit and Notify MUST be able to associate a
> failure notification (Notify) with the related submitted payload(Submit).
> In case the notification of payload is supported, the RMP MUST be able to
> associate a received payload(Notify) with a previously submitted
> payload(Submit)."
> 
> ==> This text or something similar was the subject of an earlier discussion
> in the TC which may not have completed to everyone's satisfaction.  I would
> prefer deleting this paragraph.  It is only an indication to the developer
> how to design their API were they to choose a direct rendering of the RMP
> component.
> 
> <JD> but this is just the counterpart requirement to what we say earlier 
> in same section
>  about the need to associate a Respond invocation to a previous Deliver 
> invocation.
> We know an RMP MUST be able to do so (this is part of the semantics of 
> Respond).
> Why then is this OK while it is not OK to require also that on the 
> Sending side,
> similarly, a Notify invocation must be associated with a previous Submit 
> invocation?
> </JD>

Agreed, I focused on the particular paragraph Chris mentioned and missed 
the previous one.  I would therefore suggest both paragraphs should be removed.