Re: [imapext] Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC

[Michael M Slusarz <[e-mail]>]

Quoting Timo Sirainen <[e-mail]>:

> On 5.3.2013, at 16.57, Alexey Melnikov <[e-mail]> wrote:
>
>> I've noticed some surge in activity related to implementing  
>> CONDSTORE (RFC 4551)/QRESYNC (RFC 5162) in both clients and  
>> servers, so I drafted a new WG charter proposal to update/clarify  
>> these:
> ..
>> So please comment on whether you think this work is worth doing and  
>> on the proposed charter text.
>
> Can we keep it on this mailing list? I've too many mailing lists already. :)
>
>> I've also posted a new version of RFC 5162bis  
>> (http://tools.ietf.org/html/draft-melnikov-5162bis-01), which  
>> addressed most (but not all) of existing errata on the document. If  
>> a new WG is to be formed, I propose that the document is used as  
>> one of the initial documents.
>
> Sounds like a good idea. I didn't read it yet, but some  
> QRESYNC/CONDSTORE things that come to my mind:
>
>  - command length limits as discussed by Michael
>  - don't allow server to send VANISHED duplicates
>  - algorithm how server uses the seq/uid mapping could be better to  
> reduce how much data to send (I was planning on thinking this  
> through but never got around to it)
>  - \recent flag changes highestmodseq? probably nobody cares and  
> makes it more difficult for server.
>  - condstore: is anyone really using per-flag modseq counters?

Adding to Timo's list of things to possibly discuss/consider:

- Make VANISHED responses mandatory - or at least an option to allow  
for this (I think I saw some placeholder text in the draft regarding  
this)

- There was discussion a few weeks ago about whether a server should  
return "ENABLED QRESYNC" or "ENABLED QRESYNC CONDSTORE" to an "ENABLE  
QRESYNC" command

- Editorial suggestion: A better discussion, or at least a more open  
discussion, that in practical use servers don't tend to "remember"  
expunged messages for long.  It was a bit confusing and tripped me up  
as a client author since this implementation detail is sort of buried  
in the server implementation sections.

E.g. Section 3.2 could probably use an example of a server that only  
remembers expunges over the last 100 modseqs and has consolidated all  
expunges before that into a single checkpointed stored value.  So  
people aren't as surprised, as I was, the first time they see a  
VANISHED FETCH of (HIGHESTMODSEQ - 50) that somehow returns tens of  
thousands of UIDs when in reality only a few were actually expunged in  
that modseq timeframe.

- condstore: this might be more of an implementation tip, but this is  
valid response in CONDSTORE that is not necessarily intuitive and  
needs to be handled:

a SELECT INBOX (CONDSTORE)
[...]
* 2 EXISTS
* OK [HIGHESTMODSEQ 5] Highest
a OK [READ-WRITE] SELECT completed.
b UID FETCH 5 (UID)
* 1 FETCH (UID 5)
* 2 FETCH (FLAGS (\Seen) MODSEQ (6))
b OK FETCH completed.

michael

___________________________________
Michael Slusarz [[e-mail]]