https://bugs.kde.org/show_bug.cgi?id=359576
--- Comment #5 from Thomas Lübking <thomas.luebk...@gmail.com> --- QnD: imply EXISTS for out of bounds FETCH Proper fix would be to queue the FETCH and retry after subsequent EXISTS, abort on EXPUNGE, would it? Does RFC3501 actually *mandate* a specific order? (Relates to IDLE problem - while the wrong order is a bit clumsy, you'll hardly get an unsolicited FETCH in another context, ie. the sequence should be determined by the client and servers aren't permitted to alter count while handling a FETCH request. Since IDLE is specified elsewehre, why should the RFC worry about the response order? If it's only implied, adding an async response handler queue might be worth consideration, but if it clearly states "wrong", that's hardly an option) Just ignoring (likewise implying EXISTS) the response seems wonky as it might legally indicate that client and server got out of sync - continuing on such condition might cause data loss?! -- You are receiving this mail because: You are watching all bug changes.
