[Imap-protocol] Re: SELECT of same mailbox
mrc at CAC.Washington.EDU
Sun Sep 25 09:21:50 PDT 2005
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
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 --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
More information about the Imap-protocol