[Imap-protocol] Re: SELECT of same mailbox

[Mark Crispin]

On Sun, 25 Sep 2005, Abhijit Menon-Sen wrote:
> Then surely BAD shouldn't be listed as a specific result of SELECT (or
> any other command) in RFC 3501?

I agree completely.  I was forced to add that broilerplate in the document 
to each command over my objections and better judgement.  It is redundant 
at best, and can be technically inaccurate as we have seen with the idea 
of "BAD" being a "result" to any command.  Worse is the implication 
(helped along by the omission of "NO" in such obvious silly cases as NOOP) 
is that this broilerplate is somehow normative to the operation of the 
command.

At the time I attempted, without success, to argue that it was better to 
describe the theory of the OK/NO/BAD trichotomy once, rather than document 
it for each command with the associated implication that this was somehow 
per-command unique behavior.

Unfortunately, we're stuck with it.  It was used as the insertion means 
for the blunder of having a NO response to SELECT do an implicit UNSELECT. 
Somehow, we have just got to understand that just because "BAD" is listed 
as a "Result" doesn't really mean that a command issues a BAD; rather 
this is just an (incredibly poor) paraphrase of the OK/NO/BAD theory.

>    6.3.1.  SELECT Command
>
>    Arguments:  mailbox name
>
>    Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
>                REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
>                UIDNEXT, UIDVALIDITY
>
>    Result:     OK - select completed, now in selected state
>                NO - select failure, now in authenticated state: no
>                     such mailbox, can't access mailbox
>                BAD - command unknown or arguments invalid

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.