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.

