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".
No, the server is broken.
If the message is "no longer available" the server should have sent an untagged expunge. If the server has not sent an untagged expunge then the message should still be available.
You are effectively saying that clients be required to know about a server state that was created by a poorly-implemented server that allows messages to become unavailable prior to the sending of an untagged expunge.
There is no reason for this. There is no reason to have a protocol state in IMAP that exists solely because a server was badly-written. There is no reason why a client should be expected to handle a state that can not happen unless a server is badly-written.
Instead, the server needs to be fixed so the state never happened.
Look at the situation more closely: earlier, the server said this message was present. Later, when a FETCH command is given, the server says it can't provide the message.
This is a server bug. Damage has occurred. Doing anything more will propagate the damage. Time to crash.
So the server is accurately reporting a change of state. The server never says that the message both exists and doesn't exist *at the same time*. It reports the truth at each moment, but of course the truth can change over time.
You have completely missed the point of IMAP.
Why do you think that I have put in all these commands and features to maintain shared state in IMAP? Do you think that I am some crazy person who dreams up needlessly complex protocol facilities that are useless because they don't do anything?
All that stuff is there for a purpose. That purpose includes making sure that scenario never happens.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
