Hi, >I still do not get what benefit a NOOPFIRST extension would get in the >discussed case.
I'm happy to explain... :-) >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. Correct, and this extension is for the "NO FETCH thing" (but, actually, would help in both cases if I think about it...) >- 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. No, it is not. That is exactly the problem. It is not allowed to send unsolicited expunge notifications, only as a result of a command OTHER than FETCH/STORE/SEARCH. So if a client gets a NO to a fetch, it SHOULD do a NOOP, but that is only stated in RFC2180, among many other things client implementors might not see :-) A [NOOPFIRST] would make it absolutely clear that the NO resulted NOT from a server error, but was sent intentionally since the client needs to get the expunge notifications before submitting another FETCH. See the point? :-) Christof
