MBOX-Line: From paul at nfg.nl  Sun Mar  4 05:31:42 2012
To: imap-protocol@u.washington.edu
From: Paul J Stevens <paul@nfg.nl>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] recent response in status command
In-Reply-To: <ACDE4DFC-35B3-4CD9-80F9-DD2AB711BBC4@iki.fi>
References: <4F53524C.3000308@nfg.nl>
	<ACDE4DFC-35B3-4CD9-80F9-DD2AB711BBC4@iki.fi>
Message-ID: <4F536EBE.7080509@nfg.nl>


Timo,

Thanks for your reply,

On 03/04/2012 12:49 PM, Timo Sirainen wrote:
>> I don't understand why a status command on a 3rd session should be able
>> to see the updated number of recent messages.

Ai, I meant: I don't understand why the 3rd session *can't* see the
updated number of recent messages.

>> The 3rd session selecting
>> the mailbox and fetching the flags *before* one of the selected sessions
>> fetch them seems perfectly valid to me.
> 
> I'm not entirely sure what you mean. Anyway, what the test is supposed to do is:
> 
>  - 1 and 2 connections have mailbox selected
>  - 1 connection APPENDs a new message
>  - most servers assign \recent flag to connection 1 before APPEND returns tagged OK

That smells to me like an implementation dependent choice, not a
protocol dictated requirement.

>  - just in case some server might have assigned it to 2nd connection, the 2nd connection does a NOOP
>  - now imaptest knows that the \recent must be in either connection 1 or connection 2 (both connections have informed the client with EXISTS that there are new messages, so the \recent flag must have been set)

I'm here to learn, but I don't see this in the specs.

Returning an updated EXISTS response in a session doesn't imply that
later on the client will actually request the message flags.

I understand a \recent flag must never be returned more than once or in
more than one session. But as I (re)read rfc3501 a \recent flag is not
assigned to a session until a FETCH FLAGS response was returned.

>  - (if there had been yet another EXAMINEd mailbox, I guess it could also show the message as \recent, but imaptest doesn't create such a connection)
>  - any further connections that SELECT/EXAMINE/STATUS the mailbox won't see the message as \recent (by definition of how \recent works)
>  - so the 3rd connection's STATUS should see updated message/unseen count, but recent count must be 0

I get the feeling there are undocumented semantics in play here. Doing a
STATUS doesn't affect the mailbox, fine. So even when a STATUS response
returns a RECENT > 0, it seems perfectly valid to me if subsequence
SELECT/FETCH on the same mailbox with the same session don't return any
messages with the \recent flag.

What the test seems to imply is that following transcript with two
sessions A and B is incorrect.

A status mailbox (messages unseen recent)
* status mailbox (messages 1 unseen 1 recent 1)
A select mailbox
* 1 exists
* 1 recent
...
A ok [read-write] select completed

B status mailbox (messages unseen recent)
* status mailbox (messages 1 unseen 1 recent 1)
B select mailbox
* 1 exists
* 1 recent
...
B ok [read-write] select completed
B fetch 1 flags
* 1 fetch (flags (\recent))
B ok fetch completed

A fetch 1 flags
* 1 fetch (flags ())
A ok fetch completed


-- 
________________________________________________________________
Paul J Stevens        pjstevns @ gmail, twitter, skype, linkedin

  * Premium Hosting Services and Web Application Consultancy *

           www.nfg.nl/info@nfg.nl/+31.85.877.99.97
________________________________________________________________

