QRESYNC

[Alexey Melnikov]

Hi David,

David Carter wrote:

> On Fri, 2 Nov 2007, Ken Murchison wrote:
>
>> I'm getting ready to implement the QRESYNC extension for the upcoming
>> LEMONADE interop.
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-06.txt 
>>
>
> Reading the Internet Draft, I'm a little puzzled by:
>
>    4.3.  Additional state required on the server
>
>    [...]
>
>    Also note that if the UIDVALIDITY of the mailbox changes [...], then
>    any state associated with expunged messages MUST be deleted as well.
>
> I'm not clear what the motivation is here given that a new UIDvalidity 
> forces a full resync from any client: no QRESYNC is possible.

The full sentence reads:

   Also note that if the UIDVALIDITY of the mailbox changes or if the
   mailbox is deleted, then any state associated with expunged messages
   MUST be deleted as well.

The main motivation behind this sentence is to say that there is no need 
to keep storing expunged modseqs once a mailbox is deleted or 
UIDVALIDITY changes.
You demonstrated that SHOULD is sufficient here.

The secondary motivation was to prevent servers from returning expunged 
modseqs if a mailbox was deleted and then recreated. In theory the newly 
created mailbox must not have the same UIDVALIDITY, but in practice 
servers like CMU don't track UIDVALIDITY of deleted/renamed mailboxes.
(At least this used to be the case.)

> This requirement is likely to be a pain for:
>
>> 1. Leverage delayed expunge which already stores state for expunged 
>> messages in cyrus.expunge (up until the records are purged by 
>> cyr_expire).
>
> Given that unexpunge assigns a new UIDvalidity to the mailbox.