Re: LC results for draft-melnikov-imap-expunged and how to move forward

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Tue Sep 26 00:52:45 2006, Ken Murchison wrote:
> Randall Gellens wrote:
> > I admit to still being confused, since based on side discussions I 
> > thought the server didn't need to store any state but would just 
> > report to the client which messages in the set no longer exist.
>
> This was my understanding as well, based on a private discussion 
> with Alexey prior to hacking up an implementation for Cyrus.

Your understanding on -01 is perfectly correct.

-00, however, required some kind of tombstone record, effectively 
linking each EXPUNGE event with a MODSEQ. (Or each EXPUNGEd message 
with a MODSEQ, if you prefer to look at things that way).

Alexey is suggesting - I think - that the client has some means of 
saying "I want to know what messages have been EXPUNGEd since X 
within UID set A", and the server can respond with one of the 
following:

a) "Here's a set of UIDs which have been EXPUNGEd since X".
b) "Sorry, I can't remember, you'll have to figure it out another 
way".
c) "I don't know, but here's a list of all UIDs in set A which do not 
exist".

Now, the current state of affairs is that the server always responds 
with (c). In -00, the server always responded with (a) [I think]. The 
ACAP method [DELETEDSINCE if you care to look it up] went for (a) 
with a fallback to (b).

Alexey's suggestion is (a) with a fallback to (c), since whichever 
way it works, the client always has the resynch within one RTT.

I firmly believe we do need some fallback from (a). I agree it's 
entirely unreasonable to expect a server to maintain significant 
extra state. By providing a fallback, we can allow server 
implementors to turn the retention of the state into a QOI issue.

However, I'm not sure what the fallback should be - (b) uses less 
bandwidth, but - potentially - more round-trips. (c) uses more 
bandwidth - potentially much more bandwidth - but uses no additional 
round-trips.

So it's a trade-off, and it might even be worthwhile to have this as 
a client-driven option. Certainly I'd really like to hear other 
client developers' view on this. Myself, I'm undecided between an 
option and (b). (c) has high costs for large, sparse mailboxes - to 
give a real-world example, the ESEARCH response for "UID SEARCH 
RETURN (ALL) 1:*" on my personal INBOX is 24k, or 9.5k when gzipped. 
By comparison, I've used 12.95k of download so far this morning 
(after compression).

That said, for compact mailboxes, irregardless of size, its very 
small.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade