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.
