[Imap-protocol] QRESYNC & Long Command Lines

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.

The concern is that I know at least some IMAP servers have a hard ~8KB  
limit on any command.  This limit would render QRESYNC useless on  
mailboxes over a certain size - or at least diminish the usefulness of  
the SELECT/EXAMINE QRESYNC parameters.  You could just do a basic  
SELECT/EXAMINE and then issue a series of

   tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE  
"mod-sequence-value" VANISHED)

commands, but that sort of defeats one of the main benefits of QRESYNC  
- synchronization in a single command.  Not to mention that this is  
not anywhere near inherently obvious from reading the RFC and runs  
directly counter to one of the main reasons for the extension as  
identified in the abstract ("gives an IMAP client the ability to  
quickly resynchronize any previously opened mailbox as part of the  
SELECT command, without the need for server-side state or **additional  
client round-trips**.")

Is this a valid concern, at least with current IMAP server implementations?

michael

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol