[Imap-protocol] SELECT of same mailbox

[Dave Cridland]

On Wed Sep  7 06:50:36 2005, Mark Crispin wrote:
> On Wed, 7 Sep 2005, Cyrus Daboo wrote:
>> a SELECT INBOX foobar
> 
> That is not a SELECT command, any more than
> 	{ select } choose your option
> or
> 	to select the best candidate for the job
> are.
> 
>> I consider the above to be a SELECT command with invalid arguments.
> 
> Do my previous examples demonstrate why this is a fallacy?  The 
> notion of "a SELECT command with invalid arguments" implies that it 
> is possible to define such a thing as distinct from random 
> nonsense; and furthermore that it is desirable to do so.
> 
> Either it is a valid IMAP command, or it is nonsense.  It muddies 
> the waters otherwise.
> 
> 
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).

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?

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.

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. I admit I don't handle this particular case of it. (I 
handle responses when no command is in progress quite happily, 
because the same processor is used for both ACAP and IMAP, and for 
ACAP, that's pretty essential.)

Dave.