Subject: [lemonade] QRESYNC message sequence match data

From: Timo Sirainen <[email-masked]>
Date: Tue, 17 Jun 2008 08:58:05 +0300

QRESYNC RFC explains only how to use the sequence match data to drop
expunges from the beginning of the mailbox, but it's also possible to
use them to drop expunges from the middle. For example:

1 select inbox (qresync (12345 1234 1:5 (1,3,5 1,5,10)))

If only message 1 has been expunged, the server has to return 1:<uid-1
of current seq 1> in VANISHED, but since it can find out that the
current seq 2 (3-1) maps to uid 5 and the current seq 4 (5-1) maps to
uid 10 there's no need to return anything else as expunged.

Has anyone yet figured out the exact algorithm for this? I tried it a
couple of months ago but since it didn't work after a couple of tries I
got annoyed and implemented only the simple version. If no-one's done it
yet I could try again and write some pseudo code.

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Tue, 17 Jun 2008 10:09:54 +0100

> uid 10 there's no need to return anything else as expunged.

The reason this works is because at the first point of mismatch, with  
MSN S and UID U, (U-1) => (S-1), and U doesn't exist. This indicates  
that the client doesn't know that U has been expunged, but also that  
it did know about all prior expunges - in other words, at (S-1), E is  
0, and at S, E is 1. (Note that I'm introducing the convenience of  
S=0 => U=0, and being rather blaisé with my maths and saying U-1 when  
I really mean the previous existing UID).

At the second mismatch, U does exist, and U => (S-1) - again, this  
indicates that E is 1, and therefore there are no unwitnessed  
expunges between the first and second mismatches.

Knowing *which* single expunge is missed is only possible if there is  
only one possibility - in this example, this will always be the case,  
since the MSN sequence given by the client in its mapping has gaps of  
only 1.

Typically, however, you'd merely be able to usefully handle the cases  
E==0, E!=0 at each point in the sequence, and (a refinement which  
isn't mentioned in the draft), dE == 0  / dE != 0 (ie, the expunges  
missed between two points on the mapping).

I'd missed the possibility of using the dE figures, that's quite  
interesting.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade