39 lines
1.7 KiB
Plaintext
39 lines
1.7 KiB
Plaintext
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>
|