Hi, > > 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. Because implementors only implement things they get bashed in their face :-) IMHO, RFC abc, subparagraph x.y with alternative this-and-that is not going to make implementors really give anything on it. A clearly stated paragraph in IMAP4rev2 would most probably do so, and clarify the issue - so a tagged no would not be "bad server juju", but an accepted way of dealing with the issue. Christof
