On Thursday, July 10, 2003, at 10:37 AM, Cyrus Daboo wrote:
In this particular instance the error might appear not to be harmful at first glance, but what if a new message arrived at the same time as the last one was expunged? In that case, the expunged message's sequence number would have been assigned to the new message and the client might have gone on to operate on that, which would be a serious mistake. Thus the original 'anomaly' was symptomatic of a much more serious problem and anything that can be done to expose what might appear to be trivial 'anomalies' is useful in helping tackle such issues.
While the sequence number (call it 42) is the same, it refers to different messages before and after the expunge, and the server has to keep track of that. Any command referring to 42 issued before the server sends the expunge notification for 42 should result in a NO, since the request was correct (at the time it was issued inside of that particular session), but the message no longer exists. Any command issued after the expunge notification was sent refers to the new instance of 42. If the server is pipelining requests it needs to place a marker in the input buffer showing when the expunge notifications were sent, and treat commands ahead of the marker as referring to the old 42. It also needs to place a marker showing when the announcement of the new 42 was sent. Anything between the two markers referring to 42 is wrong, and gets a BAD response. This, combined with the IMAP command sequencing rules, *should* prevent any ambiguity.
Cyrus, can you show a protocol session sequence where the above claim is not true? I can't come up with one, but if it exists, we have a problem that needs fixing.
--lyndon
