The message shouldn't go away until that EXPUNGE [response] has happened.So does this mean the EXPUNGE response should also be withheld from the client that sent the EXPUNGE command, since the message has not yet really been removed?
Not at all. It took effect in that session.
Think of EXPUNGE as being similar to unlink() of a file. It deletes the link, but the file is not destroyed until all links (which does not apply in IMAP) and all open file descriptors on the file (equivalent to sessions having the file SELECTed) are closed.
IMAP is nice in that it can "close the open file descriptor" by issuing an untagged EXPUNGE instead of requiring that the mailbox be deSELECTed.
Why is client complexity more important than server complexity?If you read RFC 2180, you are immediately struck by something (or should be): all the listed strategies but one require substantial client complexity to work around what should be a server-internal issue. That should indicate to you that that one strategy is the right one, and the others listed there are bogus.
As the kids would say, "clients rule, servers drool."
There are many more clients out there than servers. If a server violates client expectations that the other servers uphold (especially when the protocol architect endorses that expectation!), then that server is broken.
Exactly what client complexity is incurred by this NO response?
The client has to recover from a condition which has an ambiguous meaning. Exactly what does it mean to say NO to a FETCH for something that was announced as being there *AND* accessible?
The finest level of IMAP access control granularity is the mailbox, not the message. Yet EACCES was brought up as a possible cause.
IMAP has a means of synchronizing shared expunges which avoids this problem. Yet sharing expunge was brought up as a possible cause.
Maybe the hard drive has gotten a head crash.
Maybe the server couldn't get enough memory at that point, but repeating the command will work.
Maybe some fascist pig sysadmin hacked the server to say NO when the load average gets too high.
The client doesn't know. The client can't know, since IMAP provides no way to pass this along in a useful way *for the client*. Maybe there can be an error message for a human, but many clients won't pass it on.
More to the point: IMAP is supposed to insulate the human user of a client from server internal issues. IMAP provide a perfect environment, where the myriad of possible OS conditions (such as file errors) simply do not happen. Violate that environment, and you've lost your IMAP session.
This seems to be a weakness in the protocol, since there is no way for the server to explicitly say exactly what has happened.Wrong -- it is a tremendous strength in the protocol! It forces server implementors to make sure that it never happens, otherwise their server is non-compliant.Why is that preferable to a more expressive protocol that lets servers be specific about what has happened, and lets client handle that case smoothly (similar to how you would have them handle NIL)?
To put it crudely: because that's the way I think. Since I designed the protocol, it follows my whims.
This incurs comlpexity on the client too - it has to reconnect.If the server doesn't allow that, then I can DOS it by holding a connection open without sending any commands that allow EXPUNGE, so no messages can ever be deleted, and the message store grows monotonically.There is a simple -- and quite compliant -- defense: * BYE Connection holding too many expunged messages
Every client in the world has to deal with the possibility of a broken connection.
Why is this preferable to sending NO, and letting the client update itself with NOOP?
Clients don't do that. Since that strategy doesn't work, it isn't preferable.
Are you saying that RFC3501 does not allow NO for FETCH? It seems quite clear to me that it is allowed.
There are currently no instances in which NO is a meaningful response to FETCH. Once upon a time, it was thought that there might be such instances.
It CAN be done. It is not easy.What confuses me is that you seem to like it this way.
Because, unlike your idea, it works and works well.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
