MBOX-Line: From dave at cridland.net  Fri Jun  7 01:01:09 2013
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
In-Reply-To: <1945792A-24F7-4F88-ACCE-279167C04BA0@isode.com>
References: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
	<1945792A-24F7-4F88-ACCE-279167C04BA0@isode.com>
Message-ID: <CAKHUCzwy3dS2Z8S2TgdCF-SCqE0wyTB7OwbY9uWa9P_3tHk6eQ@mail.gmail.com>

On Fri, Jun 7, 2013 at 8:22 AM, Alexey Melnikov
<alexey.melnikov@isode.com>wrote:

> On 6 Jun 2013, at 21:15, Jan Kundr?t <jkt@flaska.net> wrote:
> > The option b) looks like a reasonable stopgap measure with a very
> limited potential for false positives. It is also implementable very
> quickly within my client. The option a) will require a bit more work, but
> it looks like something more "robust" than b).
>
> Option a) looks quite unreliable (and dangerous) to me.
> I hope newer versions of UW don't suffer from this.
>
>
Yes, go for (b); it's what I'd do. (In fact, Inky possible already does
this).

I might see if I can knock out an RFC 4731 bis which clarifies this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130607/dd8a8f15/attachment.html>
