MBOX-Line: From alexey.melnikov at isode.com  Wed Aug 21 09:30:43 2013
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] Multiple non-waiting UID SEARCH commands
In-Reply-To: <CAC4RtVCT_d6_-LJ=_WCLD6SWtueR_Nae=ZN-ytAthaG3fROu=g@mail.gmail.com>
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>
	<CAC4RtVCT_d6_-LJ=_WCLD6SWtueR_Nae=ZN-ytAthaG3fROu=g@mail.gmail.com>
Message-ID: <5214EB33.8020105@isode.com>

On 21/08/2013 17:10, Barry Leiba wrote:
>> 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.
+1.



