MBOX-Line: From slusarz at curecanti.org  Sat Mar  2 20:02:12 2013
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] QRESYNC & Long Command Lines
In-Reply-To: <8100D6D4-66F1-40C4-A9B2-6A03F8CCC175@iki.fi>
References: <20130218002432.Horde.oHbZYiST0vPMI_hKIDlLvg1@bigworm.curecanti.org>
	<8100D6D4-66F1-40C4-A9B2-6A03F8CCC175@iki.fi>
Message-ID: <20130302210212.Horde.q66x7X5K6O_eEUdg-T5_zg1@bigworm.curecanti.org>

Quoting Timo Sirainen <tss@iki.fi>:

> On 18.2.2013, at 9.24, Michael M Slusarz <slusarz@curecanti.org> wrote:
>
>> There seems to be a conflict between the recommendations in RFC  
>> 2683 [3.2.1.5] and the QRESYNC extension to the SELECT/EXAMINE  
>> command.
>>
>> A user recently reported an issue involving an overly long UID list  
>> passed to the FETCH command.  Although not using caching  
>> themselves, while analyzing the issue I quickly realized that there  
>> could potentially be issues in passing a lengthy cached UID list to  
>> SELECT/EXAMINE.
>>
>> This particular user's mailbox contained 6-digit UIDs that were not  
>> sequential.  In this hypothetical:
>>
>> - 1500 cached messages
>> - non-sequential UIDs
>> - All UIDs are 6 digits
>>
>> ...the UID string alone would be approximately 10500 characters  
>> (1500 UIDs * 6 characters + 1499 ',' characters).  This doesn't  
>> factor in the rest of the command - or even the optional 4th  
>> sequence match parameter.  Obviously, the 1000 character limit for  
>> outgoing client IMAP commands suggested in RFC 2683 has pretty much  
>> been obsoleted.
>
> I don't think the idea was to provide all the known UIDs. The first  
> UID range is about giving FLAGS replies only those ones listed. I  
> think it's basically always 1:<last UID you know of>. Or if you  
> happen to be doing something more special where you're caching only  
> a partial state of the mailbox, you could decide to create for  
> example max. 1000 bytes of UID string and then start merging the UID  
> ranges. You'll get a few bytes of more data but it shouldn't matter  
> that much.

Our client NEVER caches the entire mailbox - only tiny view windows  
(100 messages/slice).  I have a trash mailbox with 100,000+ messages.   
I am never going to load that entire mailbox into memory/cache.  At  
best, I will open the mailbox (loading, say, 100 message in the  
slice), do a search to find what I need (loading up to another 100  
unique messages), and maybe move around the search results a bit  
(possibly loading another 100-200 messages as I do a bit of  
scrolling).  So I only have 400 messages in my cache.  I most  
certainly do not want flag changes for the entire mailbox.

But with the command size limitations I do have to make some  
compromises for long UID lists.  So I picked an arbitrary sequence-set  
length which, when exceeded, we necessarily fall-back to a <first  
known UID>:<last known UID> range.  I guess I could get fancier and  
try to optimize this more -- e.g. cut out UID "holes" over a certain  
length -- but seems like a waste of time since I've never actually  
heard of a SELECT/EXAMINE failing with our software due to a long UID  
string in the 4 years we have implemented QRESYNC.  So this is more of  
a theoretical exercise than anything else.

michael


