Subject: [imapext] CONDSTORE / QRESYNC

From: Ken Murchison <[email-masked]>
Date: Mon, 10 Jun 2013 15:48:05 -0400

I have quickly read Alexey's refresh of these specs and they both seems 
to capture the relevant errata and implementation experience.

I think that we might want to consider combining both specs into one 
document since they are so tightly coupled to one another, especially 
given that we really want clients to support QRESYNC (and not just 
CONDSTORE) as mentioned in the last 2 paragraphs of section 1 or QRESYNC.

FWIW, Cyrus IMAP fully supports both extensions including errata 
1807-1809, with the exception of the MODIFIED response code.  Cyrus does 
not support separate per-metadata modseq, and always returns unsolicited 
FETCH responses for changed messages, so I don't know if the lack of a 
MODIFIED response code is an issue for client implementations.  I don't 
believe that it would be a heavy lift to add MODIFIED to Cyrus.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Jun 2013 11:39:28 +0100

> believe that it would be a heavy lift to add MODIFIED to Cyrus.
As a client developer, I've never actually used UNCHANGEDSINCE, but I could
understand the need to, and I'd prefer to have the MODIFIED response code
present for this case.

On the other hand, I cannot think of a case when I'd actually want
per-metadata MODSEQ - it's also not clear to me that any extant servers
actually support this anyway. In the absence of per-metadata MODSEQ, then a
client can add a flag if the message is still unseen (for example), which
seems to me to be a more useful case.

Does any server actually implement per-metadata MODSEQ? Does anyone want
this?

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 11 Jun 2013 15:38:03 +0300

On 11.6.2013, at 13.39, Dave Cridland <[email-masked]> wrote:

> On the other hand, I cannot think of a case when I'd actually want per-metadata MODSEQ - it's also not clear to me that any extant servers actually support this anyway. In the absence of per-metadata MODSEQ, then a client can add a flag if the message is still unseen (for example), which seems to me to be a more useful case.
> 
> Does any server actually implement per-metadata MODSEQ? Does anyone want this?

Perhaps it could be a useful difference for message flag changes vs. annotation changes. But I haven't implemented annotation support yet, so I'm not really sure.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Jun 2013 14:49:56 +0100

On Tue, Jun 11, 2013 at 1:38 PM, Timo Sirainen <[email-masked]> wrote:

> Perhaps it could be a useful difference for message flag changes vs.
> annotation changes. But I haven't implemented annotation support yet, so
> I'm not really sure.
>
>

One possible option there would be to call this out as out of scope, and
require the annotation extension to have its own modification sequence.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Jun 2013 20:13:25 +0100

On 11/06/2013 14:49, Dave Cridland wrote:
> On Tue, Jun 11, 2013 at 1:38 PM, Timo Sirainen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 11.6.2013, at 13.39, Dave Cridland <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > On the other hand, I cannot think of a case when I'd actually
>     want per-metadata MODSEQ - it's also not clear to me that any
>     extant servers actually support this anyway. In the absence of
>     per-metadata MODSEQ, then a client can add a flag if the message
>     is still unseen (for example), which seems to me to be a more
>     useful case.
>     >
>     Perhaps it could be a useful difference for message flag changes
>     vs. annotation changes. But I haven't implemented annotation
>     support yet, so I'm not really sure.
>
>
>
> One possible option there would be to call this out as out of scope, 
> and require the annotation extension to have its own modification 
> sequence.
If this is a question of what to say in CONDSTORE, I would be Ok with 
that. For example saying something like "CONDSTORE requires one modseq 
per all flags/keywords. Other IMAP extensions might add additional 
modseqs for other metadata (or might reuse the flag one)." would be Ok. 
I would be less happy with modifying existing syntax (apart from 
removing something which is already optional) or requiring other 
extensions to use their own per-metadata modseqs.