Hi Stefan,
Maybe I am looking at this in a simplistic way, but I can
not follow the issue you have with the current proposal and how the alternate
proposal addresses the issue.
It seems to me the fundemantal problem is for the RMS to
determine the state of the RMD (thus resolving doubt) Thus, if the RMD were to
send the final acknowledgement along with the ack ranges that indicate the
messages that are received by the RMD, RMS has enough information to reconcile
its own status with the RMD (basically it can diff the sequence numbers to
obtain those messages which were in doubt but confirmed to be received by the
RMD per the final ack). I am not clear as to why we need to do more here.
Perhaps you can clarify for me why your proposal is a better proposal and
what the problem that Doug's proposal is not solving. It seems to me that in
both cases the protocol is changed, but the proposal you are making is more
complicated but functionally equivalent. I would like to understand the
motivation for the complexity.
Thanks!,
--umit
From: Stefan Batres
[mailto:]
Sent: Tuesday, Sep 13, 2005 12:50
PM
To:
Subject: [ws-rx] New
proposal for i019 and i1028
All,
After much discussion Doug has
managed to make me understand his reasons for proposing his Close/FinalAck
mechanism for addressing i019 and i028. We now agree, an accurate
acknowledgement state can be helpful in order to resolve doubt and in
addition, for cases where a sequence must be ended, that acknowledgement state
must be final. These are preconditions for recovery and the protocol can aid
in establishing these preconditions.
However, we still have an issue
with the current proposal [1]. We think it conflates the notions of resolving
doubt and closing sequences. Attached is an alternate proposal that we believe
addresses this issue, allows for the exact semantics [1] provides and has
other advantages. Details are in the document.
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00084.html
I look forward to the group’s
comments.
Thanks,
--Stefan
