MBOX-Line: From barryleiba at computer.org  Wed Aug 21 09:10:15 2013
To: imap-protocol@u.washington.edu
From: Barry Leiba <barryleiba@computer.org>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] Multiple non-waiting UID SEARCH commands
In-Reply-To: <133DA207-C219-4676-9D97-9EC5167D41E7@iki.fi>
References: <520A622E-1A91-4B04-AD6F-361896D439F5@lasselog.com>
	<5214A27E.8030300@isode.com>
	<CAC4RtVDtTBK6EOGtqJNkCQewgc-ZpMMOMq=046j+Umh6H6imvA@mail.gmail.com>
	<5214D7D7.8080100@isode.com>
	<8A80BED6-24C0-45D1-AE80-DCB8C79FA4E8@lasselog.com>
	<133DA207-C219-4676-9D97-9EC5167D41E7@iki.fi>
Message-ID: <CAC4RtVCT_d6_-LJ=_WCLD6SWtueR_Nae=ZN-ytAthaG3fROu=g@mail.gmail.com>

> I don't remember if that was really intentional though, since the main idea was to
> be able to send other commands during a long SEARCH, not really to be able to
> send another SEARCH. It requires adding extra code to prevent that. I think I'll
> probably add that, since although I'm not convinced the current way is violating
> RFC 3501, it's also not very helpful behavior for clients. But of course it'll take
> 10 years before most of the existing servers are upgraded..

I don't think any SEARCH pipelining is helpful to clients -- that's a
large part of the reason we did ESEARCH.  Because the search results
come in untagged, unlabelled responses that can't be correlated with
the search criteria that match them, any client that tries to pipeline
SEARCH commands is misguided, and is asking for trouble.

So I don't think you should spend your time on "fixing" this.

Barry

