MBOX-Line: From jkt at flaska.net  Fri Feb  8 13:11:00 2013
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Re: QRESYNC Questions
In-Reply-To: <1360356725.26278.140661188781457.3532161E@webmail.messagingengine.com>
References: <201302081451.r18EpC0d010777@mxout11.cac.washington.edu>
	<7237e649-33b3-47fb-a99a-4d3e7f28030f@flaska.net>
	<1360356725.26278.140661188781457.3532161E@webmail.messagingengine.com>
Message-ID: <196b59fe-4582-4880-8ce2-b358f1207e15@flaska.net>

On Friday, 8 February 2013 21:52:05 CEST, Bron Gondwana wrote:
>> I have one suggestion for the actual implementation: please 
>> don't ever send EXPUNGE when QRESYNC is enabled, and never 
>> reference other UIDs in VANISHED than those which have been 
>> just expunged. These restrictions are not mandated by the 
>> current version of the RFC, but are very important for clients 
>> (they prevent an ambiguous state where the client suddenly 
>> doesn't know which UIDs still remain in the mailbox).
>
> This one could be tricky depending on your backend. Cyrus does 
> it right for changes, but may need to tell "gaps" during SELECT 
> depending on storage settings.

I meant VANISHED, not VANISHED EARLIER in this context. Sending superfluous UIDs in VANISHED EARLIER doesn't lead to inconsistency. The spec even mentions that this might be required under certain situations (hence the optional facility for telling the server about the client's UID mapping).

With kind regards,
Jan

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

