On Fri, 2 Jan 2004, Christian Kratzer wrote:
can you perhaps further elaborate on your thoughts on why exactly you feel that an untagged NO FETCH response is evil.
Clients don't handle it the way that you think they do. They expect that if they issue a proper FETCH, that it will work work; and if it doesn't work then it's "horrible error 69."
Allow me to second this.
I'd like to suggest that when
S: * NO Some of those messages were expunged, please NOOP
is changed to
S: * NO [NOOPFIRST] Some of those messages were expunged
what will actually happen is that the dialog box will include [NOOPFIRST] in addition to what's already there.
You'll notice that my recommendation is listed first (4.1.1), and the untagged NO or dummy data options are listed second and third (4.1.2 and 4.1.3).
As it turns out, 4.1.1 and 4.1.4 (avoid the problem entirely) turned out to be the only successful strategies. This is because the client never encounters an unexpected situation with these strategies. Not surprising clients is always the winning strategy.
A well-known server implements 4.1.3 (dummy messages), and in practice, it seems to work out. Either the client caches and doesn't ask questions that would show the server is inconsistent, or the client doesn't cache and doesn't know the server is inconsistent. That is, there's a problem, but both of the likely client implementations tend to cover it up quite nicely.
I don't want to defend the practice too much, as it's clearly cheating, but I can't recall any complaints. I want to second Timo's observation that since this just doesn't happen that often, it's pretty hard to claim to have comprehensive data about the problem.
I saw a server bug that would occasionally return NO to a FETCH that was actually valid, due to an internal server bug unrelated to EXPUNGE. This did not work well with clients. They throw up the Dialog Box of Doom and users get very confused. Responding NO to a FETCH is accusing the client of having a bug, and is treated by some clients as such.
Of course, if you only respond NO to EXPUNGE-FETCH problems, that's not as bad as my bug was--my server was returning NO to perfectly valid FETCHes. These happened a lot more often than the EXPUNGE-FETCH case. While I suspect NO will be handled badly, it will probably just never happen.
NOOPFIRST is not a bad idea, but it is not very useful. There are other workable solutions to this problem. NOOPFIRST purports to improve 4.1.2, but in practice, it probably can't. Clients should probably NOOP after a NO to FETCH anyway in all cases.
Tim
