33 lines
1.4 KiB
Plaintext
33 lines
1.4 KiB
Plaintext
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.
|
|
|