I'd favor a "NO command" to subsequent FETCH/STORE/SEARCH like in 4.1.2, so my question was if this is also ok for concurrent access like described in my earlier mail. If anyone could answer that, I'd be happy.
In general, responding NO to innocuous client commands, especially those that the client has no knowledge of why they should fail, is a bad idea and will translate directly into user complaints.
There isn't enough machine-parseable information in an IMAP response for the client to figure out that it should NOOP and re-try the request. Most clients punt the problem to the user, who usually knows even less about IMAP than the client does, and you get a very poor error message. Even worse, it's the server's problem--the client did nothing wrong.
I've seen clients handle NO to valid FETCH commands badly. Most clients throw up a cryptic IMAP error dialog, "Server responded: NO Messages missing" or something equally impossible to figure out. I suspect NO to SEARCH will also result in the same cryptic dialog. NO to STORE is a little more common, I suspect most clients know how to deal with that. (Actually that's easy: you just throw the flag changes out if the message is gone.)
Dummy messages for missing messages seem to work well in practice. Having experienced this, and having considered what certain dominant clients do with dropped connections, I would prefer dummy messages to dropped connections or NO responses.
Tim
