mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] condstore mod-sequence 0

E-mail headers
From: Johnathan Galton <johngalton217@gmail.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:49 -0000
Message-ID: CABHfyPRv5dojb7NUVjAVdpVsE+8EHqnvrn1cgwyV1FiwvOOgYg@mail.gmail.com permalink / raw / eml / mbox 
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>
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:49 -0000
Message-ID: E3EECF90-B68B-4BCF-88C1-8FEA6B5A7BBA@iki.fi permalink / raw / eml / mbox 
On 4.12.2012, at 2.46, Johnathan Galton 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.

According to RFC 4551 ABNF it's illegal for client to send CHANGEDSINCE 0. It simply shouldn't include the CHANGESINCE parameter if it wants to fetch everything. It wouldn't be wrong for servers to simply reject this command with a BAD reply.
Reply
E-mail headers
From: johngalton217@gmail.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:49 -0000
Message-ID: CABHfyPQkqKxXg9w7dvy-ZpiBrKahsZNGaowji-8jHK1j-m-6gg@mail.gmail.com permalink / raw / eml / mbox 
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>
Reply