Hi, On 11 Mar 2003 10:48:52 +0000, David Woodhouse <[EMAIL PROTECTED]> wrote... > On Tue, 2003-03-11 at 10:39, Mark Keasling wrote: > > There is no race condition. When the client sends the idle command, it > > is telling the server to send notification about new mail as it arrives. > > Since new mail has already arrived prior to the initiation of the IDLE > > command, the server should immediately notify the client about the new mail > > and then continue to send updates as they occur. > > You said 'should' and I agree with that wholeheartedly. It's common > sense and obviously the correct thing to do. It'd be utterly stupid to > do otherwise. > > But you didn't say 'MUST' in capitals :)
Okay, I've had to dig out RFC2060 and thumb through it. Here is the relevant text... 5.2. Mailbox Size and Message Status Updates At any time, a server can send data that the client did not request. Sometimes, such behavior is REQUIRED. For example, agents other than the server MAY add messages to the mailbox (e.g. new mail delivery), change the flags of message in the mailbox (e.g. simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly. Special rules exist for server notification of a client about the removal of messages to prevent synchronization errors; see the description of the EXPUNGE response for more detail. 7. Server Responses <...> An example of unilateral untagged server data occurs when the IMAP connection is in selected state. In selected state, the server checks the mailbox for new messages as part of command execution. Normally, this is part of the execution of every command; hence, a NOOP command suffices to check for new messages. If new messages are found, the server sends untagged EXISTS and RECENT responses reflecting the new size of the mailbox. Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages. You will notice that the RFC has MUST. > My concern is that you can't always rely on implementors to apply common > sense, but you _can_ rely on them to deviate as far as possible from > common sense while staying technically within the bounds of the RFC (and > even that only if you're lucky :). A server can not remain compliant with RFC2060 and not send mailbox size updates at its first opportunity which is the at the latest the next command sent by the client. The server can't change its notion of the mailbox size without informing the client. The size can grow at any time. There are limits however on when the server can tell the client that it has shrunk. The IDLE extension is a way for the client to start an command essentially asking the server for updates in real time. The server can then send updates as frequently or not as it chooses. This eliminates the need for a constant stream of NOOP commands to achieve the same result. A server which fails to notify the client of new mail isn't exactly useful IMHO. Regards, Mark Keasling <[EMAIL PROTECTED]>
