Subject: [imapext] qresync WG adoption call

From: Dave Cridland <[email-masked]>
Date: Mon, 20 May 2013 19:20:26 +0100

Folks,

We now have two drafts by Alexey published:

 - draft-melnikov-rfc4551-bis-00 (CONDSTORE)
 - draft-melnikov-5162bis-00 (QRESYNC)

I'd like to propose that the working group adopt these as our start point.

Therefore this constitutes a call for adoption of both documents; reviews
would be very useful at this stage and I'll prod people if there's no
volunteers.

Thanks,

Dave. (As qresync co-chairman)

---

From: Michael M Slusarz <[email-masked]>
Date: Mon, 20 May 2013 13:53:03 -0600

> I'd like to propose that the working group adopt these as our start point.

Does this mean the current inclination is to issue updates of the  
current documents rather than trying to combine into a single "IMAP  
synchronization extensions" doc?

I personally feel the latter makes more sense from a protocol  
implementor's standpoint, especially since the subtleties and  
interplay between the two extensions could more easily be explained.   
Although I understand this requires drafting of an entirely new  
document rather than incremental tweaking of existing text.

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 May 2013 21:20:08 +0100

As co-chairman:

On Mon, May 20, 2013 at 8:53 PM, Michael M Slusarz <[email-masked]>wrote:

> Does this mean the current inclination is to issue updates of the current
> documents rather than trying to combine into a single "IMAP synchronization
> extensions" doc?
>
>
It means this is the current proposal on the table, not that a single
document is ruled out. Either is explicitly allowed by our charter.
Adopting these as working group drafts would not preclude either, as far as
I'm concerned - once they're the working group's, we can do whatever we
have consensus on.

> implementor's standpoint, especially since the subtleties and interplay
> between the two extensions could more easily be explained.  Although I
> understand this requires drafting of an entirely new document rather than
> incremental tweaking of existing text.
>

There's pros and cons each way; if anyone feels strongly (or would like to
explore the pros and cons) feel free to speak up.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 23 May 2013 10:01:47 +0100

> document rather than incremental tweaking of existing text.
As Dave said, our WG Charter doesn't restrict us in what we can do here. 
If people want a single document, my preferred way of doing that would be:
1) first post 2 separate drafts updating CONDSTORE and QRESYNC first (so 
that people can use wdiff to see what changed)
2) then produce a combined document with CONDSTORE inserted into QRESYNC 
(again, so that people can diff relevant parts)
3) start rearranging & rewriting text to make sure that CONDSTORE and 
QRESYNC bits are consistent with each other.

This is going to be more work, but I am happy to try if people see benefits.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 May 2013 11:27:40 +0100

> would be very useful at this stage and I'll prod people if there's no
Given we have only one response (which I can't actually read as being in
favour or not), I'm going to repeat this call - we need some noise, in
favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 May 2013 13:11:56 +0200

<co-chair hat on>

I'm going to echo Dave's point.  This organization does its best work
when there are many eyes and its worst when people don't pay attention. 
If this work is important to you, PLEASE take a few minutes to read both
documents and comment on this call for adoption.

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:
> On Mon, May 20, 2013 at 7:20 PM, Dave Cridland <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Therefore this constitutes a call for adoption of both documents;
>     reviews would be very useful at this stage and I'll prod people if
>     there's no volunteers.
>
>
> Given we have only one response (which I can't actually read as being
> in favour or not), I'm going to repeat this call - we need some noise,
> in favour or against.
>
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 23 May 2013 11:16:03 +0000

we already have support for CONDSTORE, but without mainstream client 
support for QRESYNC (esp with current status of Thunderbird) it's hard 
to justify the investment (refactoring to allow persistence of 
information about deleted messages) in that one.

So I would be keen to implement it, but I'd want to see some indication 
that popular clients are going to use it.

Also would be great if we could get a universal modseq for the entire 
user account, so you can query for changed folders.

Adrien

------ Original Message ------
From: "Eliot Lear" <[email-masked]>
To: "Dave Cridland" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 23/05/2013 11:11:56 p.m.
Subject: [imapext] WG participants please READ Re: qresync WG adoption 
call
>  If this work is important to you, PLEASE take a few minutes to read 
>both documents and comment on this call for adoption.
>
>Eliot
>
>>_______________________________________________ imapext mailing list 
>>[email-masked]://www.ietf.org/mailman/listinfo/imapext
>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 May 2013 09:18:19 -0400

Hi Dave,

> I'd like to propose that the working group adopt these as our start point.

+1

-- 
Cyrus Daboo

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 23 May 2013 22:30:08 +0300

> I'd like to propose that the working group adopt these as our start point.

OK.

> Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers.

I don't think rfc4551-bis has any actual content changes compared to rfc4551? Some new things that come to my mind:

1. Dovecot doesn't enable modseq tracking until client has requested it in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT:

* OK [NOMODSEQ] No permanent modsequences

I know at least one client thought this meant that modseqs couldn't be used even if CONDSTORE enabling command was used. I'm thinking about changing this so that highestmodseq is tracked always in any case, but that's not the easiest change. Anyway, should the -bis RFC mention something about this?

2. Per-metadata item modseqs. I didn't pay attention to this previously since I wasn't planning on implementing it anyway. But now looking at it..:

>    UNCHANGEDSINCE <mod-sequence>
> 
>       However, if the mod-sequence of any metadata item of the message
>       is greater than the specified UNCHANGEDSINCE value, then the
>       requested operation MUST NOT be performed.

…
>    Note: A client trying to make an atomic change to the state of a
>    particular metadata item (or a set of metadata items) should be
>    prepared to deal with the case when the server returns the MODIFIED
>    response code if the state of the metadata item being watched hasn't
>    changed (but the state of some other metadata item has).  This is
>    necessary, because some servers don't store separate mod-sequences
>    for different metadata items.

The last sentence seems to be somewhat wrong, because that would be necessary even if the server stores separate mod-sequences.

So as far as I see, the only benefit of having per-metadata modseqs would be for SEARCH MODSEQ? Seems like the document talks about per-metadata modseqs a bit too much when its usefulness is very limited, and somehow I doubt there will ever be many server implementations for it.

It talks also about private vs. shared modseqs. I recently had trouble with figuring out how to do these, since private and shared modseq counters are stored in completely different places. I ended up simply incrementing the shared modseq counter to a message every time its private flag was changed, which isn't ideal of course. Anyway, again SEARCH exposes this shared vs private difference, but there's no way to do that with FETCH.

So I'm wondering if there's really any benefit in keeping the per-metadata and shared vs private modseqs functionality in the -bis RFC? Is anyone ever going to really implement them? Maybe just allow client to give those parameters and have server ignore them.

If the CONDSTORE -bis RFC is trimmed down, it might be useful to merge it with QRESYNC -bis, but currently I think it's a bit too bloaty. And I guess it would make it more difficult to figure out which functionality is CONDSTORE and which is QRESYNC. But maybe it shouldn't even try, and would assume clients/servers would always implement both CONDSTORE+QRESYNC?

---

From: Tony Hansen <[email-masked]>
Date: Thu, 23 May 2013 15:40:30 -0400

+1

I also like the idea of a combined document, following Alexey's outlined
approach.

    Tony Hansen

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 23 May 2013 21:36:00 +0100

On 23 May 2013, at 20:30, Timo Sirainen <[email-masked]> wrote:

> I don't think rfc4551-bis has any actual content changes compared to rfc4551?

3 errata are addressed, mostly minor.

(I will reply to the rest of your message in a separate email.)

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 23 May 2013 22:33:06 +0200

On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote:
> 1. Dovecot doesn't enable modseq tracking until client has 
> requested it in some way by enabling CONDSTORE or QRESYNC. Until 
> then it says at SELECT:
>

This is probably worth explaining in the updated version. I see the benefits of not tracking MODSEQs when not ever requested, but I also understand that clients might want to set a local "don't bother with MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can also see that a client might want to open a mailbox and bypass the usual sycnhronization steps (perhaps it just wants to quickly fetch an item, etc), so the use case for a MODSEQ-supporting client not enabling MODSEQs within some sessions seems valid to me. It's a corner case with potential to cause unpleasant surprises.

Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC.

Do you have any numbers on how much performance is gained by not tracking the MODSEQs -- i.e. is your optimization actually worth the complexity?

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 23 May 2013 21:51:32 +0000

are you talking about using the client setting to determine whether the 
server will track / store modseqs?

this seems dangerous.  The server never knows when it will be asked by a 
client for modseq, so if it supports it, it should track them always.  
It's common for the same mailbox to be accessed by multiple different 
agents (e.g. desktop + iOS)

As for deprecating shared/private and metadata modseq... +1

Adrien

------ Original Message ------
From: "Jan Kundrát" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 24/05/2013 8:33:06 a.m.
Subject: [imapext] Re: qresync WG adoption call
>>1. Dovecot doesn't enable modseq tracking until client has requested 
>>it in some way by enabling CONDSTORE or QRESYNC. Until then it says at 
>>SELECT:
>>
>This is probably worth explaining in the updated version. I see the 
>benefits of not tracking MODSEQs when not ever requested, but I also 
>understand that clients might want to set a local "don't bother with 
>MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can 
>also see that a client might want to open a mailbox and bypass the 
>usual sycnhronization steps (perhaps it just wants to quickly fetch an 
>item, etc), so the use case for a MODSEQ-supporting client not enabling 
>MODSEQs within some sessions seems valid to me. It's a corner case with 
>potential to cause unpleasant surprises.
>
>Originally, I wanted to suggest not returning either of HIGHESTMODSEQ 
>or NOMODSEQ at SELECT time, but this is explicitly forbidden by the 
>RFC.
>
>Do you have any numbers on how much performance is gained by not 
>tracking the MODSEQs -- i.e. is your optimization actually worth the 
>complexity?
>
>Cheers,
>Jan
>
>-- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Jan Kundrát <[email-masked]>
Date: Fri, 24 May 2013 00:00:12 +0200

On Thursday, 23 May 2013 23:51:32 CEST, Adrien W. de Croy wrote:
> are you talking about using the client setting to determine 
> whether the server will track / store modseqs?
>
> this seems dangerous.  The server never knows when it will be 
> asked by a client for modseq, so if it supports it, it should 
> track them always.  It's common for the same mailbox to be 
> accessed by multiple different agents (e.g. desktop + iOS)

Hi Adrian,
Dovecot defers creating MODSEQs until they are "enabled" for a mailbox for the first time. This "enabling" happens apparently when the client opens a mailbox after having issued a "CONDSTORE-enabling command" for the first time. This is a safe optimization -- MODSEQs are turned on as soon as they are required. After that, they are apparently always tracked even if the user never executes a CONDSTORE-enabling command, ever.

Some users access their mailboxes only from clients which do not issue ENABLE CONDSTORE, ENABLE QRESYNC or any other similar command. His point is, apparently, that there is no point in having the MODSEQs tracked under these circumstances. Unfortunately, they only way to do so under RFC 4551 is rather strange, via the NOMODSEQ, and some clients are apparently confused by that. I cannot blame them.

Cheers,
Jan

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 24 May 2013 01:49:22 +0300

> Do you have any numbers on how much performance is gained by not tracking the MODSEQs -- i.e. is your optimization actually worth the complexity?

It's getting less and less useful. Originally when nobody really used them and Dovecot was using only Maildir, where adding extra 64bits to each message did about double the (heap) memory usage for a mailbox. But nowadays other mailbox formats use up more memory already and modseqs are very useful for other purposes as well (dsync mainly), so they are getting enabled more and more often anyway. The complexity now would be to change the code so it wouldn't need to be explicitly enabled :)

Mainly I was thinking that the comment in RFC could be about how NOMODSEQ was already used for this purpose, and/or recommending that if somebody else plans on doing that they would keep tracking the highestmodseq regardless of whether per-message modseqs are being tracked.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 May 2013 14:17:27 +0100

Hi Adrien,

On 23/05/2013 12:16, Adrien W. de Croy wrote:
> we already have support for CONDSTORE,

Will you be interested in helping on clarifying/cleaning up the 
CONDSTORE document?

> but without mainstream client support for QRESYNC (esp with current 
> status of Thunderbird) it's hard to justify the investment 
> (refactoring to allow persistence of information about deleted 
> messages) in that one.
> So I would be keen to implement it, but I'd want to see some 
> indication that popular clients are going to use it.

I can't tell you about popular clients (Thunderbird, Apple Mail, Windows 
Live/Outlook). But I know there are several mobile and desktop clients 
(some of them in development) that make/will make use of QRESYNC.

> user account, so you can query for changed folders.

I think this was discussed before and this looks like another extension. 
(Several server implementations store per folder modseqs, so it might be 
a problem for them).

>> when there are many eyes and its worst when people don't pay 
>> attention.  If this work is important to you, PLEASE take a few 
>> minutes to read both documents and comment on this call for adoption.
>>
>> Eliot
>>
>>>     Therefore this constitutes a call for adoption of both
>>>     documents; reviews would be very useful at this stage and I'll
>>>     prod people if there's no volunteers.
>>>
>>>
>>> Given we have only one response (which I can't actually read as 
>>> being in favour or not), I'm going to repeat this call - we need 
>>> some noise, in favour or against.
>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 May 2013 14:33:02 +0100

On 23/05/2013 21:33, Jan Kundrát wrote:
>> it in some way by enabling CONDSTORE or QRESYNC. Until then it says 
>> at SELECT:
>>
> item, etc), so the use case for a MODSEQ-supporting client not 
> enabling MODSEQs within some sessions seems valid to me. It's a corner 
> case with potential to cause unpleasant surprises.

I know of a client that sometimes opens mailboxes without enabling 
CONDSTORE or QRESYNC, especially when a mailbox is opened for the first 
time. This client might also be confused by this behaviour.
On the other hand, the client might ENABLE CONDSTORE unconditionally, so 
this might not actually be a problem.

> or NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 May 2013 14:51:04 +0100

Hi Timo,

> On 20.5.2013, at 21.20, Dave Cridland <[email-masked]> wrote:
  [...]
> I know at least one client thought this meant that modseqs couldn't be used even if CONDSTORE enabling command was used. I'm thinking about changing this so that highestmodseq is tracked always in…

I do find your use case a bit problematic on the client side, but the 
document can talk about this. What do you think the advice should be?

> ...
> *The last sentence seems to be somewhat wrong, because that would be necessary even if the server stores separate mod-sequences.*
>
> It talks also about private vs. shared modseqs. I recently had trouble with figuring out how to do these, since private and shared modseq counters are stored in completely different places. I ended up simply incrementing the shared modseq counter to a message every time its private flag was changed, which isn't ideal of course. Anyway, again SEARCH exposes this shared vs private difference,
Can you explain how SEARCH is doing that?
> but there's no way to do that with FETCH.
>
> So I'm wondering if there's really any benefit in keeping the per-metadata
This was done to integrate with the ANNOTATION extension. If people are 
not interested in doing this, this can be dropped.
> and shared vs private modseqs functionality in the -bis RFC?

I think this is more of an implementation detail, but we can review what 
the document says and possibly simplify.

> Is anyone ever going to really implement them? Maybe just allow client to give those parameters and have server ignore them.
>
> If the CONDSTORE -bis RFC is trimmed down, it might be useful to merge it with QRESYNC -bis, but currently I think it's a bit too bloaty. And I guess it would make it more difficult to figure out which functionality is CONDSTORE and which is QRESYNC.

I think group commands (or their extensions) into QRESYNC specific and 
generic CONDSTORE/QRESYNC would make sense.

> But maybe it shouldn't even try, and would assume clients/servers would always implement both CONDSTORE+QRESYNC?

I think the difference is still important for clients which have to cope 
with only CONDSTORE being present. While I would love for all servers 
implementing CONDSTORE to also implement QRESYNC, I expect that to take 
some time.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 25 May 2013 22:55:22 +0000

Hi Alexey

------ Original Message ------
From: "Alexey Melnikov" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "Eliot Lear" 
<[email-masked]>; "Dave Cridland" <[email-masked]>
Sent: 25/05/2013 1:17:27 a.m.
Subject: Re: [imapext] WG participants please READ Re: qresync WG 
adoption call
>>#03f8d723c825408abd7c65fe8494e360 BLOCKQUOTE.cite {PADDING-LEFT: 10px; 
>>MARGIN-LEFT: 5px; BORDER-LEFT: #000000 1px solid; PADDING-RIGHT: 0px; 
>>MARGIN-RIGHT: 0px} #03f8d723c825408abd7c65fe8494e360 .plain PRE, 
>>.plain TT {FONT-SIZE: 100%; FONT-FAMILY: monospace; FONT-WEIGHT: 
>>normal; FONT-STYLE: normal} #03f8d723c825408abd7c65fe8494e360, 
>>03f8d723c825408abd7c65fe8494e360 .plain PRE, .plain TT {FONT-SIZE: 
>>12pt; FONT-FAMILY: Tahoma}
>>
I'd be interested but I don't have much spare bandwidth at the moment.  
What did you have in mind?  It was a while ago that we implemented 
CONDSTORE, and I don't recall finding any issues with the RFC at the 
time.

However we only looked at it hard enough for our implementation.

>I can't tell you about popular clients (Thunderbird, Apple Mail, 
>Windows Live/Outlook). But I know there are several mobile and desktop 
>clients (some of them in development) that make/will make use of 
>QRESYNC.
is anyone on this list a maintainer of thunderbird?

>I think this was discussed before and this looks like another 
>extension. (Several server implementations store per folder modseqs, so 
>it might be a problem for them).
we use per-folder modseq I'm pretty sure.  But could overlay another one 
I guess.

When you have 500 folders or more, it's a real problem when one agent 
filters mail, for another agent to discover this.  At the moment the 
agents need to iterate all folders to discover where the mail has gone.

In general, compared to messages, folders in IMAP are IMO second class 
citizens.  No way to advertise folder deletion, renaming etc.

What could be interesting would be a virtual/meta-folder called 
"FOLDERS", which treats every folder as a record in this virtual folder. 
  Then you could just do a modseq on this.

Again, out of scope for this.

Adrien

>>From: "Eliot Lear" mailto:[email-masked]
>>To: "Dave Cridland" mailto:[email-masked]
>>Cc: mailto:[email-masked]:[email-masked]
>>>>On Mon, May 20, 2013 at 7:20 PM, Dave Cridland 
>>>>mailto:[email-masked] wrote:

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 26 May 2013 03:33:38 +0300

On 26.5.2013, at 1.55, Adrien W. de Croy <[email-masked]> wrote:

>>> but without mainstream client support for QRESYNC (esp with current status of Thunderbird) it's hard to justify the investment (refactoring to allow persistence of information about deleted messages) in that one.
>>>  
>>> So I would be keen to implement it, but I'd want to see some indication that popular clients are going to use it.
>> 
>> I can't tell you about popular clients (Thunderbird, Apple Mail, Windows Live/Outlook). But I know there are several mobile and desktop clients (some of them in development) that make/will make use of QRESYNC.

Unfortunately it looks like Thunderbird won't be implementing any new features anytime soon. I know there's a patch for SPECIAL-USE already done, but they won't merge that.

>>> Also would be great if we could get a universal modseq for the entire user account, so you can query for changed folders.
>> 
>> I think this was discussed before and this looks like another extension. (Several server implementations store per folder modseqs, so it might be a problem for them).
> we use per-folder modseq I'm pretty sure.  But could overlay another one I guess.
>  
> When you have 500 folders or more, it's a real problem when one agent filters mail, for another agent to discover this.  At the moment the agents need to iterate all folders to discover where the mail has gone.

Clients can find out folders that have changed since the last time by keeping track of their HIGHESTMODSEQ. With LIST-STATUS extension it could be done with one command. Yeah, requires a bit more effort than a single global HIGHESTMODSEQ, but I think it's good enough. Also for active sessions there is the possibility of using NOTIFY..

> In general, compared to messages, folders in IMAP are IMO second class citizens.  No way to advertise folder deletion, renaming etc.
>  
> What could be interesting would be a virtual/meta-folder called "FOLDERS", which treats every folder as a record in this virtual folder.  Then you could just do a modseq on this.

I've solved this internally in Dovecot by giving a GUID for each mailbox, which allows tracking renames and deletions. Mails also have GUIDs. I wonder if clients would be interested in having a standard GUID extension for these..

>  Again, out of scope for this.

Yeah.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 26 May 2013 12:25:29 +0100

> I've solved this internally in Dovecot by giving a GUID for each mailbox, which allows tracking renames and deletions. Mails also have GUIDs. I wonder if clients would be interested in having a sta…

I would be happy to look a this/participate in discussions, especially if somebody writes a draft.

But can I please ask people to concentrate on 1 thing at a time? I would like to finish QRESYNC update this summer, if possible.

---

From: Michael M Slusarz <[email-masked]>
Date: Sun, 26 May 2013 22:53:15 -0600

Quoting "Adrien W. de Croy" <[email-masked]>:

> support for QRESYNC (esp with current status of Thunderbird) it's  
> hard to justify the investment (refactoring to allow persistence of  

As someone who implemented a CONDSTORE client first, and then added  
QRESYNC support (albeit both were 4 years ago), my experience is that  
it is an incremental improvement.  Meaning the learning curve between  
the two is drastically flatter.  It is why I brought up the issue of  
combining the documents at some point, since -- again, with my  
client-side implementer cap on -- it would have been preferable to  
have it all in a single location.  As mentioned, not super-relevant at  
the present time as this can be discussed later.

Those documents seem like appropriate starting points to me.  Note: I  
noticed RFC 5162 has a bis-01 version but the original thread e-mail  
refers to bis-00.

What follows is off the top of my head experiences that may be useful  
to address in some fashion.  I believe they are all QRESYNC specific.   
Might be premature, but figured its better to speak sooner than later:

+ My main wish list request for QRESYNC support would be to mandate  
VANISHED responses on QRESYNC enabling.  It looks like the draft is  
leaning in that direction, at least according to a text placeholder.

+ From recent discussions on one of the IMAP lists somewhere, I recall  
discussion about the proper ENABLED response when doing a ENABLE  
QRESYNC command - e.g.

1 ENABLE QRESYNC
* ENABLED QRESYNC
-or-
* ENABLED QRESYNC CONDSTORE
1 OK

Might be useful to clarify this.

+ A reminder of command length limitations and/or a defined command  
length limitation for QRESYNC commands since a QRESYNC SELECT/EXAMINE  
can easily contain 1000's of bytes of UID and/or sequence data.   
Unlike commands like FETCH/STORE, which can be split and pipelined,  
the ~1000 byte limitation in RFC 2683 doesn't scale well and can't  
easily be worked around.  Obviously you can compress sequence strings  
by converting into broader ranges, but this can result into a bunch of  
unneeded data being returned.

+ The text regarding VANISHED results is confusing.  Specifically the  
fact that servers are allowed to "checkpoint" modseq data to limit  
storage size.  i.e. the first time you see something like this:

1 UID FETCH 1:* (UID) (CHANGEDSINCE 50000 VANISHED)
1 OK
2 UID STORE 10000 +FLAGS \deleted
* 1 FETCH (UID 10000 MODSEQ (50001) FLAGS (\Deleted))
2 OK
3 UID EXPUNGE 10000
* VANISHED 10000
3 OK [HIGHESTMODSEQ 50002]
4 UID FETCH 1:* (UID) (CHANGEDSINCE 50000 VANISHED)
* VANISHED (EARLIER) 1:10000
4 OK

Perfectly valid server response, but surprising the first time you run  
into something like it.

michael