MBOX-Line: From johngalton217 at gmail.com  Mon Dec  3 17:19:51 2012
To: imap-protocol@u.washington.edu
From: Johnathan Galton <johngalton217@gmail.com>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] Re: condstore mod-sequence 0
In-Reply-To: <CABHfyPRv5dojb7NUVjAVdpVsE+8EHqnvrn1cgwyV1FiwvOOgYg@mail.gmail.com>
References: <CABHfyPRv5dojb7NUVjAVdpVsE+8EHqnvrn1cgwyV1FiwvOOgYg@mail.gmail.com>
Message-ID: <CABHfyPQkqKxXg9w7dvy-ZpiBrKahsZNGaowji-8jHK1j-m-6gg@mail.gmail.com>

On Mon, Dec 3, 2012 at 4:46 PM, Johnathan Galton <johngalton217@gmail.com>wrote:

> In section 3.3.1 of RFC 4551 it says for FETCH to only return messages
> where the mod-sequence of the message is "bigger than" that specified (i.e.
> ">").  However, it seems reasonable for clients to be able to say "FETCH
> ... (CHANGEDSINCE 0)" and retrieve *all* messages (AFAICT thunderbird does
> this initially), however 0 isn't "bigger than" any valid value that we may
> store for the mod-sequence of a message.
>

Oops, actually this last sentence is incorrect because having a message's
mod-sequence of 0 is invalid ("*positive* unsigned 64-bit value") despite
being quite useful as a default/initial value.


>
> How do other folks handle this?  Is 0 explicitly special cased to mean "do
> not filter anything" in the server implementation even though (based on my
> reading) against the letter of the RFC?
>
> Interestingly enough in SEARCH MODSEQ (in section 3.4) is explicitly ">=".
>  Seems a little incongruent, not sure if it's intentional or not.
>
> Thanks for your time,
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121203/8781f44c/attachment.html>
