Pawel Salek <[EMAIL PROTECTED]> wrote: > I have impression two distinct issues are mixed here:
Yes, good point. > a. critical server errors (ENOMEM, etc) ... > I would insist that the server should try _hard_ to avoid reporting NO > on a-type condition. It is the server's task to handle these issues and > a measure of its quality. ISTM there are two things to consider: whether the error is transient, and whether it prevents the server from handling other commands. I all cases, I am thinking only of basic OS errors that cannot be prevented by the server implementation. (Thinking of these as "impossible" is clearly a mistake, since they do happen.) I don't think it's helpful to hide such errors, nor to design protocols that make it difficult to report them. If the error is transient, then it may make sense to report NO and hope the error has cleared up by the time the client sends another command. Or it may make sense to simply try the operation again, and respond only after the next attempt. (E.g., for EINTR.) Alternatively, and especially if it is a resource-shortage problem, it may make sense to drop the connection, hope that the client will silently reconnect, and hope that this will help free up the needed resources. ENFILE is an example of this kind of error. If the error is not transient, and it prevents the server from handling any further commands, then we might as well drop the connection, but of course we should still also report the error. On some systems, ENOMEM could be an example of this kind of error. If the error is not transient, but does not necessarily prevent the server from handling other commands, then it makes sense to report the error with NO, but still keep the connection open so further commands can be attempted. > b. expunges done on a (multiaccess) mailbox by other means. ... > Scenario 4.1.2 is probably the one that you would prefer - NO tagged > response at the end. Yes. > I think OK is better because NO is likely to pop up an error message > on a situation which is not an error but just an shared expunge. You > do want to get a pop up on failed imap operations, don't you? Sure. And if the client requests a message that was just deleted by another client, then it makes sense to me that the user should be notified. > but I can imagine that some servers may have choose to expunge ASAP > for, say, confidentiality reasons. Even ignoring confidentiality, it still makes sense to remove the messages immediately for the sake of being honest to the client that sent EXPUNGE. AFAICT, the only way to be honest to that client and also to a concurrent client that hasn't had a chance to find out about the expunge, is to use NO. > This probably is a single best reason to interleave SEARCH and FETCH > commands with NOOP or IDLE so that servers can inform about EXPUNGEs as > soon as possible. Sure. But server implementors still have to somehow handle the case when clients don't do that. paul
