94 lines
3.4 KiB
Plaintext
94 lines
3.4 KiB
Plaintext
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
|
|
________________________________________________________________
|
|
|