Re: [apps-discuss] Extentions of IMAP4

[John C Klensin <[e-mail]>]

--On Friday, July 22, 2011 11:16 +0100 Dave Cridland
<[e-mail]> wrote:

> On Fri Jul 22 09:12:35 2011, [e-mail] wrote:
>> [Yan LU] The intention of this draft is to associate multiple
>>  identities
>> belonging to one user. Thus, after logging in, the user may
>> choose   one of
>> these associated identities, under each of which there can be
>> an   INBOX, a
>> SENTBOX and other folders, as shown in the following figure.
> 
> OK. In the SASL model, an authentication identifier can have
> access to many authorization identifiers already; so no change
> is needed here.

Let me add one much more general observation to Dave's specific
ones:

IMO, IMAP is arguably already much too big and too complicated,
at least partially due to the addition of features that provide
different ways to do the same thing.  In principle, adding more
optional features should not be a problem, but they make it very
hard for a user to predict what will be available from different
combinations of clients and servers.  That situation, in turn,
makes easy movement among clients on multiple devices less
likely and more difficult.

The LEMOMADE effort was supposed to improve on that situation.
As far as I can call, it did not succeed in that particular
goal; some would claim it made things worse.

To me, the best evidence for "much too big and too complicated"
is the very small number of available, well-designed, IMAP
clients that are fully-conformant to the protocol and up-to-date
on the majority of current features and extensions.  Some years
ago, an important contributor and developer of IMAP and other
email protocols observed that "all IMAP clients suck, <xxx>
sucks less than the others" (name omitted to avoid a distracting
side discussion).   If one adds the criterion that they be
tracking the efforts in the EAI WG that will require
modifications for, e.g.,  non-ASCII addresses, the number goes
down even further.

So, for whatever it is worth, I think the community should be
looking only at additional IMAP changes and extensions for which
there is a compelling need for a large number of users -- a need
that is compelling enough that we can assume that a large
fraction of client and server implementers will actually support
the proposed feature.   I believe the EAI i18n changes meet that
criterion.  These two proposals do not, not just for the reasons
Dave mentions, but because we haven't seen much evidence a huge
number of such users, because there are other ways around the
issue in IMAP (as Dave notes), and because a slightly different
organization of mailboxes and folders on the server (and a
competent client) can accomplish almost exactly the same thing
without any protocol changes at all.   I have some evidence for
the latter: I've been doing things that way, with standard IMAP
(and without a requirement for any of the very recent
extensions), for 15 years or so now.

    john