--On Thursday, July 10, 2003 01:36:13 PM -0600 Lyndon Nerenberg <[EMAIL PROTECTED]> wrote:
| 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.
Correct - and we are talking about the 'in between two markers' case here which should/must generate BAD.
| 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.
I don't think there is anything broken other than the original issue of the client using an invalid sequence number in SEARCH which should/must return BAD.
-- Cyrus Daboo
