27 lines
1.2 KiB
Plaintext
27 lines
1.2 KiB
Plaintext
MBOX-Line: From johngalton217 at gmail.com Mon Dec 3 16:46:57 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Johnathan Galton <johngalton217@gmail.com>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] condstore mod-sequence 0
|
|
Message-ID: <CABHfyPRv5dojb7NUVjAVdpVsE+8EHqnvrn1cgwyV1FiwvOOgYg@mail.gmail.com>
|
|
|
|
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.
|
|
|
|
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/60481c4d/attachment.html>
|