MBOX-Line: From gds at chartertn.net  Thu Nov 29 11:34:19 2018
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Thu Nov 29 11:34:45 2018
Subject: [Imap-protocol] Unsolicited server responses
In-Reply-To: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
References: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
Message-ID: <f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>

On 10/17/18 20:17, Aaron Burrow wrote:
> 
> Given that the server can unilaterally send updates to the client, why 
> was the IDLE extension useful/necessary?

I'm no expert but I don't think I have seen an IMAP server that sends 
unsolicited EXISTS or EXPUNGE responses when not in IDLE mode. These 
untagged responses only occur in idle or when a client request occurs 
first, e.g., NOOP. But you are right, RFC 3501 does say that the server 
MAY send untagged messages at any time without a client request 
occurring first.

The IDLE RFC 2177 gives a hint as to why IDLE is needed with this 
statement:

"While the spec [RFC3501 I assume] actually does allow a server to push 
EXISTS responses asynchronously, a client can't expect this behavior and 
must poll."

So the IDLE capability and command provide a way for the client to know 
for sure that asynchronous responses can occur and prepare to receive 
them and not have to poll.

I have recently been contributing to the Thunderbird imap code. I am not 
sure that it will correctly respond to unsolicited/asynchronous (out of 
the blue) EXISTS responses unless idle mode has been entered, although 
per RFC 3501 all clients should.

-gene




