Re: [apps-discuss] Extentions of IMAP4

John C Klensin <john-ietf@jck.com> Fri, 22 July 2011 12:35 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE321F8586 for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 05:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.639
X-Spam-Level:
X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUlSOacANu4V for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 05:35:17 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6321F855C for <apps-discuss@ietf.org>; Fri, 22 Jul 2011 05:35:17 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QkEwb-000Bzz-Qe; Fri, 22 Jul 2011 08:35:06 -0400
Date: Fri, 22 Jul 2011 08:35:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: Dave Cridland <dave@cridland.net>, luyan@zte.com.cn, General discussion of application-layer protocols <apps-discuss@ietf.org>, ding.xin@zte.com.cn, jiaxw9@chinaunicom.cn, "SHIH, JERRY \\(ATTSI\\)" <JS9053@att.com>
Message-ID: <A4579F2D196ADD22F47363BE@PST.JCK.COM>
In-Reply-To: <9031.1311329770.120161@puncture>
References: <OFC24805BE.30C38C8A-ON482578D5.002C72D9-482578D5.002D5311@zte.com.cn> <9031.1311329770.120161@puncture>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2011 12:35:18 -0000

--On Friday, July 22, 2011 11:16 +0100 Dave Cridland
<dave@cridland.net> wrote:

> On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn 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