If the client deletes a message it wasn't able to download, then that sounds like a buggy client.
Why?
If we have learned anything in the past several years, it is that the imagination of programmers as to what can go wrong in such circumstances is far more limited than the possibilities of what will go wrong (and what can be exploited).That's exactly why I prefer the simle tactic of reporting any errors when they happen.
What you fail to miss is, excuse the shouting, that CLIENTS DO NOT RELIABLY PASS SERVER MESSAGES TO THE USER!!!!!
Repeat: CLIENTS DO NOT RELIABLY PASS SERVER MESSAGES TO THE USER!!!!!
There are several clients that I have first-hand experience with that NEVER show ANY server messages to the user. Some of these clients are written for a non-English speaking market. Others are intended to be purely graphical.
A "NO" response to a FETCH is meaningless, and leads to unpredictable results. The only thing that is reliably done well is an indication that the session crashed.
I still don't know exactly what constitutes "horrible error #69" in your mind.We've been taking about a message which disappeared unexpectedly and outside of the scope of the protocol.Or within the scope of the protocol, by another client. Is that horrible?
Yes, because if that happens your server is broken. It isn't allowed to expunge the message until it announces the message via EXPUNGE.
There are many many things (even in quite well populated messages) that can be NIL with well-stated rules of what that means.Right - and where do those rules include the meaing "this message is no longer present"? Where do they include the possibility of a data item formerly being non-NIL, but later becoming NIL?
They don't. Which means that you can't do it.
I specifically designed the protocol to prevent that from happening. I am specifically telling you not to do it.
How can I possibly be any more clear?
A null pointer is analogous to NO, which means that the value is undefined.Right. NO is NULL; NIL is 0. I don't like NIL for a missing message, for the same reason that we don't like *NULL==0.
There is no "NO" here. There is no such thing as a "missing message".
A client may have local storage of some messages. In the case of a shared mailbox, the user might want to retain some messages even if another user deletes them from the IMAP mailbox. But if the server returns NIL, that may overwrite the local previously-stored message.
Wrong. Read RFC 3501, section 6.4.5, page 54:
Most data items, identified in the formal syntax under the
msg-att-static rule, are static and MUST NOT change for any
particular message. Other data items, identified in the formal
syntax under the msg-att-dynamic rule, MAY change, either as a
result of a STORE command or due to external events.This has the effect of nullifying sections 4.1.2 and 4.1.3 of RFC 2180 (which, by the way, is Informational and thus is not normative to IMAP). You have to choose either 4.1.1 or 4.1.4.
This is similar to your download-and-delete example, but the difference is that with NO, the lossage is the client's fault; with NIL, it's the server's fault.
That statement is based upon a false premise, and thus the entire statement is meaningless.
I don't consider concurrent deletion to be a bug, or an unreasonable state. The protocol is expressive enough to allow it to happen, even though the server can't be entirely specific about what has happened.
Concurrent deletion requires that the deletion be announced with untagged EXPUNGE before it takes place.
It's the same as with UNIX files; unlinking the last link does not affect open file descriptors.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
