MBOX-Line: From lyndon at orthanc.ca  Tue Dec 11 13:03:04 2012
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] BINARY for broken MIME parts
In-Reply-To: <CABa8R6t+ogP2XcUqqGVxcUAp-kk+dNwuyKftLKTFhUjkRR1wZQ@mail.gmail.com>
References: <CDD9BF88-A87D-41CB-A668-E2A7FE5CFE20@iki.fi>
	<50C0A8F4.4070405@isode.com>
	<809DCB83-1507-4F6B-8B70-D86042569C46@iki.fi>
	<CABa8R6tJV4iOjgckqLzEqLcdifRnVj6+g_7cB1vNd3YTgSt4pw@mail.gmail.com>
	<20121211133659.Horde.l5mdoRCy0RtyMMLrnOij-Q1@bigworm.curecanti.org>
	<CABa8R6t+ogP2XcUqqGVxcUAp-kk+dNwuyKftLKTFhUjkRR1wZQ@mail.gmail.com>
Message-ID: <7A294188-31BB-4C43-8D13-6BE9B413E472@orthanc.ca>


On 2012-12-11, at 12:47 PM, Brandon Long wrote:

> In general, I haven't understood the new error responses as "replacements" for ALERT, as they're not backward compatible.  A client which gets an error response is doesn't understand does what, nothing?  So if I change an ALERT to a CANNOT, I'm just having clients which don't know CANNOT drop information instead of helping the user.

ALERT almost always generates a blocking popup in the UI containing the raw error text string from the server.  This information is almost always useless to any end user, and just serves to annoy them.

There are only two cases where I generate an ALERT: for an administrative server shutdown (e.g. a MOTD style 'server down for maintenance until 0630' message), or when the user's auth credentials are not useable (e.g. 'your password has expired').

--lyndon


