MBOX-Line: From dave at cridland.net  Wed Sep  7 12:12:40 2005
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] SELECT of same mailbox
In-Reply-To: <Pine.OSX.4.63.0509070901430.28350@pangtzu.panda.com>
References: <UsPqTMxta5Q38J/4ek2JBA.md5@bluegrass.trish.de>
	<5b93232d050907075812659c02@mail.google.com>
	<5b93232d05090708031a898592@mail.google.com>
	<Pine.OSX.4.63.0509070901430.28350@pangtzu.panda.com>
Message-ID: <20596.1126120360.592254@peirce.dave.cridland.net>

On Wed Sep  7 03:20:25 2005, Mark Crispin wrote:
> Historically, a SELECT which failed with a NO did not change state 
> either, although RFC 1176 was unclear on that point.  This was 
> "fixed" in RFC 1730 so that a SELECT which failed with a NO always 
> left you in authenticated state.  This had the effect of creating a 
> NO response which changes state.
> 
> IMHO, this is not a good thing.  It was a desirable feature that 
> IMAP guaranteed that command failures did not change state; that 
> feature has been lost forever.  Of course, it seemed "right" at the 
> time (and arguably still does) that you shouldn't be selected after 
> a SELECT fails, and that's why I didn't object to that change.  Mea 
> culpa.

Personally I like it. It means that where I need to perform an 
UNSELECT, but the server doesn't support that, I can issue a known 
bogus SELECT. (In fact, I do: SELECT "&#-&#/#")

Dave.

