IMAP is *read-write*. Writes based upon damaged reads are -- by definition -- creation of new damage.Can you give a concrete example? I'm having a hard time imagining how this could happen.
Download-and-delete. A single message couldn't be accessed because of a protection failure, but it was quite deleteable.
However, what is more important is to recognize that the fact that you can't imagine how it could happen does not prove that it can not happen. What we are talking about is the server entering a state which should not happened. 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).
Think of it this way -- suppose liability laws were changed so that the software vendors could be sued for damages. You'd be a lot more careful about your presumptions.
And exactly how is the server going to accomplish that?Further clobbering an already clobbered file would be bad, and it should not be possible to do it by accident, so a noisy warning and confirmation request would be in order if the user tries that.We were talking about a text editor at that point, not an IMAP server. You brought it up. Myself, I don't think the analogy is very good.
An IMAP server *is* a text editor. It's a text editor that is removed from the user.
Some piece of data in the editor disappears unexpectedly. Do we continue editing the rest of the file as if nothing happened?
Think about what happens if the client author thinks like you do, and tries to bluff through what should be "horrible error #69, must crash" conditions.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. That's pretty horrible. It isn't supposed to happen, and the protocol gives no provision for it happening.
perhaps you remember BSD UNIX on VAX, where references through a null pointer would happily return 0.To me, that sounds a lot like an IMAP server that returns NIL values instead of a NO response in the case of a deleted (or otherwise inaccessible) message.
Nope. NIL is a defined value, with defined semantics. Refer to the syntax rules in RFC 3501. There are many many things (even in quite well populated messages) that can be NIL with well-stated rules of what that means.
A null pointer is analogous to NO, which means that the value is undefined.
Haven't you encountered sysadmin who ignore your problem reports because they assume that anything short of a complete failure must be a user error?I don't think additional gratuitous failure is an appropriate response.
It isn't additional gratuitous failure. Due to a server bug, the server entered a state that it never should have entered, and since IMAP does not express that state the server has to crash.
I guess I was unclear. I meant that the state of the mailbox would change over time, and the server should accurately report the present state at any given time.
IMAP has ways to express those changes. Changes must occur within that framework.
Changes which occur outside that framework are bugs. IMAP does not permit such changes. If such changes happen, the server is broken and needs to be fixed.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
