Re: [imapext] qresync WG adoption call

[Timo Sirainen <[e-mail]>]

On 20.5.2013, at 21.20, Dave Cridland <[e-mail]> wrote:

> 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.

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?