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.
