43 lines
1.6 KiB
Plaintext
43 lines
1.6 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|