mailing list archives

When can and should a server send data the client hasn?t requested?
RFC3501#2.2.2 says ?A client MUST be prepared to accept any server response
at all times. This includes server data that was not requested.? Looking at
the semantics of the server responses, only EXISTS, RECENT, EXPUNGE and
FETCH stipulate sending ?unrequested? data.

Should this be interpreted, ?In theory the server can send whatever
responses whenever it wants.  In practice, it just sends those four
piggybacked on command completion responses if there?s an unreported
mailbox update.?

Given that the server can unilaterally send updates to the client, why was
the IDLE extension useful/necessary?

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20181017/2982282f/attachment.html>

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

>> 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.

I've co-written one that sends a sends a very small number of responses and 
then stops, which hasn't caused problems. I've heard that another server 
sent an unlimited number of responses using blocking i/o, and that would 
cause problems if the client wasn't listening.

IIRC more servers send unsolicited responses occasionally, to keep NAT 
middleboxes from discarding the connection.

> "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."

That's the key.

Arnt