Ok. AFAICS, then, there is no wiggle room - NO is listed as a valid response to FETCH, and any client that can't handle it is in violation. Servers are entirely within their rights if they send NO, though of course it's preferable to prevent the problem if possible.
Pawel Salek already answered this.
Why should those be the only two choices? Certainly the error should be reported. Allowing the user to see the rest of the file, in itself, doesn't do any harm.
IMAP is *read-write*. Writes based upon damaged reads are -- by definition -- creation of new damage.
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.
And exactly how is the server going to accomplish that?
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. In particular, think about GUI clients that hide all server messages from the user on the grounds that such messages are "unfriendly."
I hesitate to say that it should be completely prohibited - protecting users from themselves is often a losing battle, and the user may know better than you, being in the thick of it.
The problem is that, as a server, you are two levels removed from the user. You do not know what the client may do.
But you seem to think that reporting the error instead of dropping the connection will also cause further data corruption for an IMAP mailbox too. How, exactly?
As stated above, IMAP is read-write. Continuing past a horrible error will cause writes based upon damaged reads.
You may be too young to remember the painful lessons of the 1970s, but perhaps you remember BSD UNIX on VAX, where references through a null pointer would happily return 0.
You prefer not being able to read any of it?I vote -- strongly -- for the latter. If can open a mailbox, then I expect to be able to read what's in it, without having some fool server say "you can read messages 1 and 3 but not 2 because of some internal implementation consideration that is invisible to you."
I prefer that what is broken gets fixed, instead of swept under the carpet. "Horrible error #69" can not be ignored by the user.
Nor, for that matter, can it be ignored by the sysadmin; this is also a problem. 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?
Isn't it also reasonable to expect that things might change over time?Why would you consider this to be a good thing?Are you saying that you'd prefer for the mailbox contents to be entirely static?
Don't be ridiculous.
You implied that the way to handle errors will change over time so as to force the client to know about a lot more things that should be private to the server.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
