MBOX-Line: From mrc at CAC.Washington.EDU  Wed Sep  7 09:20:25 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: <5b93232d05090708031a898592@mail.google.com>
References: <UsPqTMxta5Q38J/4ek2JBA.md5@bluegrass.trish.de>
	<5b93232d050907075812659c02@mail.google.com>
	<5b93232d05090708031a898592@mail.google.com>
Message-ID: <Pine.OSX.4.63.0509070901430.28350@pangtzu.panda.com>

On Wed, 7 Sep 2005, Rob Siemborski wrote:
> Actually, this isn't quite right either, because of the possibility of
> failure of a SELECT command, which implies to me the entire paragraph
> is bogus (since the original text didn't address this case).

I don't see why it needs to address this case.  The fact that it does not 
address this case indicates that this case does not matter for the 
purposes of that paragraph.

What is more interesting is the difference between BAD and NO.

Historically, both BAD and NO had the same semantics of causing no change 
to state.  We still see that today, in the requirement that COPY and 
multiple APPEND must succeed or fail atomically.

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.

-- 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.

