On 02.01.2004 11:20 +0100 Christof Drescher <[EMAIL PROTECTED]> wrote:
As an extension like "[NOOPFIRST]" or similar can only be mean something like "a client SHOULD noop and try again" (but cannot be a MUST so it does not break anything), it falls more into a clarification than a real extension. It does not bother any "perfect world" implementors, but may make "real world" implementors have a look at it.
I still do not get what benefit a NOOPFIRST extension would get in the discussed case.
If a message is expunged in session A and the server has not yet been able to notify session B of the expunged messages and session B subsequently sends a FETCH command for the expunged messages:
- We have an open discussion if the server should respond with the expunged message or send a tagged NO FETCH response. IMHO both options are valid and should be left for the implementation to decide.
- After sending whatever reply to the client for the FETCH the server can send the unsolicited expunge notifcations and the session will be in sync. So I do not see the requirement for a NOOPFIRST extension. It would be more or less redundant and unnecessarily complicate the protocol.
Greetings Christian
-- Christian Kratzer [EMAIL PROTECTED] CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136
