MBOX-Line: From jkt at flaska.net  Wed Aug 21 05:29:05 2013
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] Multiple non-waiting UID SEARCH commands
In-Reply-To: <520A622E-1A91-4B04-AD6F-361896D439F5@lasselog.com>
References: <520A622E-1A91-4B04-AD6F-361896D439F5@lasselog.com>
Message-ID: <13d1f255-73e7-4bfd-83ec-bfc1bd5278e6@flaska.net>

On Wednesday, 21 August 2013 12:26:50 CEST, Lasse Jansen wrote:
> As none of the commands contain message sequence numbers, I 
> would say this should be allowed.

In my understanding of the RFC, even though you are allowed to send this, 
the result you get might not match your expectations, as others have 
explained in this thread.

The command to implement here is ESEARCH which:

a) solves your pipelining problem neatly and properly,
b) allows for further compression of the result via the min:max syntax,
c) is nowadays supported even by GMail

Furthermore, if your IMAP server supports CONDSTORE (again, GMail nowadays 
does), you can save yourself some traffic during the flag resynchronization 
by using FETCH CHANGEDSINCE.

There is one more uncertainity with the SEARCH response -- some sources 
(see the whole thread at [1]) support the interpretation that it is OK to 
actually send the SEARCH data for a single command split into multiple 
responses which are to be joined by the client. I wonder if this is valid. 
My understanding of RFC3501 wording is that such behavior is *not* correct 
and that there should always be exactly one SEARCH response to each SEARCH 
command, but my client will join them anyway. I wasn't able to pinpoint 
some authoritative source which made me change this, unfortunately.

With kind regards,
Jan

[1] http://www.mail-archive.com/imap@u.washington.edu/msg02127.html

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

