On 2004.03.24 17:27, Paul Jarc wrote:
Pawel Salek <[EMAIL PROTECTED]> wrote: > Server that answers NO follows the specification but is useless.
If the message is, in fact, no longer available by the time FETCH arrives, then I would instead call it "honest".
I have impression two distinct issues are mixed here: a. critical server errors (ENOMEM, etc) b. expunges done on a (multiaccess) mailbox by other means.
I think it is critical to decide which case exactly is being discussed.
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.
b-type cases are described in an _informational_ rfc 2180 as you might probably know already. In particular, section 4. addresses exactly this point. Three scenarios are presented. scenario 4.1.1 assumes that the server still has full control over the mailstore and knows what is going on. Scenario 4.1.2 is probably the one that you would prefer - NO tagged response at the end. I would say that scenario 4.1.3 is as good - server sends NIL for expunged message(s).
The meaning of scenarios of 4.1.2 is esentially the same. The difference is in whether OK or NO response code is sent. Since the FETCH is followed by unsolicited EXPUNGE responses sent at nearest next opportunity, it probably does not matter which one is sent. 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?
My feeling is that 4.1.1 is the most optimal from a client's and user's standpoints ("When I click on the message I expect to see it, dammit!") but I can imagine that some servers may have choose to expunge ASAP for, say, confidentiality reasons.
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.
Pawel
