78 lines
3.8 KiB
Plaintext
78 lines
3.8 KiB
Plaintext
MBOX-Line: From MRC at CAC.Washington.EDU Wed Sep 7 15:08:03 2005
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <MRC@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:36 2018
|
|
Subject: [Imap-protocol] SELECT of same mailbox
|
|
In-Reply-To: <20596.1126126367.510966@peirce.dave.cridland.net>
|
|
References: <8613FB1A1827570EC6B5150F@ninevah.cyrusoft.com>
|
|
<Pine.OSX.4.63.0509071108110.28350@pangtzu.panda.com>
|
|
<DC4E58A90D144DDA3A10024D@ninevah.cyrusoft.com>
|
|
<Pine.WNT.4.64.0509071235060.3496@Shimo-Tomobiki.panda.com>
|
|
<20596.1126126367.510966@peirce.dave.cridland.net>
|
|
Message-ID: <Pine.WNT.4.64.0509071441180.3720@Tomobiki-Cho.CAC.Washington.EDU>
|
|
|
|
On Wed, 7 Sep 2005, Dave Cridland wrote:
|
|
> There's another thing to consider, besides your implication that a client
|
|
> sending random rubbish that happened to begin similarly to a SELECT command
|
|
> would end up changing state; there's no way for the client to know if it was
|
|
> recognised as a SELECT command with invalid syntax (Which issues BAD), or
|
|
> unrecognised as a SELECT command at all (Which issues BAD).
|
|
|
|
Indeed; thank you for pointing out yet another reason why IMAP does not
|
|
have the concept of "recognized command with bad syntax".
|
|
|
|
> Another amusing thing with SELECT - when does the server change state for an
|
|
> OK or NO? When it sends the tagged response, or prior to that? If, given a
|
|
> client in selected state on mailbox Foo, something like:
|
|
> C: A01 SELECT Bar
|
|
> S: * 50 EXISTS
|
|
> S: [...] Normal SELECT untagged responses, including another EXISTS.
|
|
> S: A01 OK
|
|
> Is that EXISTS for Foo, or Bar? And how does the client know?
|
|
|
|
Indeed; this is a known wart in the protocol. It's an important reason
|
|
why no server generally sends responses when no command is in progress,
|
|
the main exception being the BYE untagged response.
|
|
|
|
> It is, of course, a completely legal time for the server to send an EXISTS
|
|
> for Foo, since it's allowed to send those when no command is in progress - it
|
|
> might have simply crossed on the wire. The only way to process that EXISTS
|
|
> would be to hold it until we either see no others before the tagged OK (in
|
|
> which case, we know the SELECT worked, and we can process it for Bar), or we
|
|
> see another (in which case... Which is for Foo and which for Bar? One assumes
|
|
> the first response is for Foo).
|
|
> The same applies for PERMANENTFLAGS, FLAGS, and presumably other responses
|
|
> that SELECT sends.
|
|
|
|
Most clients don't go to that length; they simply assume that any
|
|
responses to SELECT apply to the selected mailbox. Or they avoid the
|
|
problem entirely by never recycling a session (that is, they never issue a
|
|
new SELECT or EXAMINE in a session).
|
|
|
|
The problem comes in when the new mailbox is smaller than the old mailbox.
|
|
I know, because early versions of UW imapd did not reliably guarantee that
|
|
SELECT would never give metadata to the previously selected mailbox.
|
|
That is why all but the most prehistoric versions of UW imapd only do the
|
|
automatic action (automatic EXISTS, RECENT, EXPUNGE, etc.) at the end of
|
|
processing a command.
|
|
|
|
> As it happens, I know of no server that sends any responses when no command
|
|
> is in progress, but RFC3501 specifically advises that this is possible.
|
|
|
|
Some people though that it was vitally important to have responses when no
|
|
command is in progress otherwise "IMAP will die" (a similar campaign was
|
|
waged about multiple commands in progress, as opposed to pipelining).
|
|
That experience reinforced my general disdain of arguments of the form
|
|
"IMAP must do <X> or IMAP will die."
|
|
|
|
That stuff is all there in an attempt to placate those individuals (not
|
|
that it did...). The only practical benefit was the limited amount of
|
|
pipelining that you can do in IMAP.
|
|
|
|
-- Mark --
|
|
|
|
http://staff.washington.edu/mrc
|
|
Science does not emerge from voting, party politics, or public debate.
|
|
Si vis pacem, para bellum.
|
|
|