26 lines
1.2 KiB
Plaintext
26 lines
1.2 KiB
Plaintext
|
MBOX-Line: From burrows.labs at gmail.com Wed Oct 17 17:17:57 2018
|
||
|
To: imap-protocol@u.washington.edu
|
||
|
From: Aaron Burrow <burrows.labs@gmail.com>
|
||
|
Date: Wed Oct 17 17:18:30 2018
|
||
|
Subject: [Imap-protocol] Unsolicited server responses
|
||
|
Message-ID: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
|
||
|
|
||
|
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>
|