MBOX-Line: From tss at iki.fi  Thu Nov  6 09:17:47 2008
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Untagged Status Notifications Async or Not?
In-Reply-To: <49132293.10733.4B89FB7@mail.sabahattin-gucukoglu.com>
References: <49132293.10733.4B89FB7@mail.sabahattin-gucukoglu.com>
Message-ID: <BB30AC22-F439-4F9D-B10C-1B072998EE34@iki.fi>

On Nov 6, 2008, at 7:00 PM, Sabahattin Gucukoglu wrote:

> I'm afraid I'm having problems with RFC 3501.  The problem is that,  
> while
> it clearly indicates that all clients absolutely MUST interpret  
> untagged
> responses sent at any time, it seems (in a rather roundabout  
> fashion) to
> imply that it is somehow proper for SELECTed mailboxes only ever to  
> inform
> clients when responding to client commands, like NOOP.  There's  
> never a
> mention of why this is so, nor any permission explicitly given (as it
> seems to me) to do the right thing and just blast untagged  
> notifications
> at the client as soon as we have them.

It's mentioned in RFC 3501:

Server implementations are permitted to send an untagged response  
(except for EXPUNGE) while there is no command in progress. Server  
implementations that send such responses MUST deal with flow control  
considerations. Specifically, they MUST either (1) verify that the  
size of the data does not exceed the underlying transport's available  
window size, or (2) use non-blocking writes.

> Apart from when dealing with client bugs, I'd like to see an IMAP  
> server I
> use push notifications at once, to have clients listen and act on them
> accordingly without requiring a minimum polling period during which  
> they
> assume complete silence for fear of soliciting any response, and all
> without needing IDLE which we will use when we clearly need to (I.E.,
> we've quite finished interfacing with the user and are now doing  
> nothing
> but wait for new mail).

Dovecot used to send them 5 years ago, but it exposed bugs in clients  
(well, I remember only one actually and that was fixed) and there  
wasn't any real upside to it anyway. All clients that can use IDLE  
already do so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20081106/d00f7158/attachment.sig>
