On 02.01.2004 15:01 +0100 Christof Drescher <[EMAIL PROTECTED]> wrote:
Hi,[snipp]
sync.- After sending whatever reply to the client for the FETCH the server can send the unsolicited expunge notifcations and the session will be inSo 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.
ok, accepted. Wasn't sure about that.
Still I would rather see clients adopting the practice of sending noops from rfc2180 than inventing another extension. It's already hard enough to get a grasp of how imap is supposed to work as it is.
If there already is a way to do it that is even documented in an rfc why should we reeinvent the wheel.
Greetings Christian
-- Christian Kratzer [EMAIL PROTECTED] CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136
