[imap5] My personal wishlist for an IMAP5

Philip Van Hoof <spam@pvanhoof.be> Tue, 26 August 2008 16:37 UTC

Return-Path: <imap5-bounces@ietf.org>
X-Original-To: imap5-archive@ietf.org
Delivered-To: ietfarch-imap5-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 59CDB3A69E2; Tue, 26 Aug 2008 09:37:12 -0700 (PDT)
X-Original-To: imap5@core3.amsl.com
Delivered-To: imap5@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0B6583A685A for <imap5@core3.amsl.com>; Tue, 26 Aug 2008 09:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id yPo00d65KM9D for <imap5@core3.amsl.com>; Tue, 26 Aug 2008 09:37:07 -0700 (PDT)
Received: from mail2.pvanhoof.be (pvanhoof.freax.org []) by core3.amsl.com (Postfix) with ESMTP id B4BA93A69E2 for <imap5@ietf.org>; Tue, 26 Aug 2008 09:37:03 -0700 (PDT)
Received: from [] (d54C0C0BA.access.telenet.be []) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.pvanhoof.be (Postfix) with ESMTP id 9E867A7F88 for <imap5@ietf.org>; Tue, 26 Aug 2008 18:19:22 +0200 (CEST)
From: Philip Van Hoof <spam@pvanhoof.be>
To: imap5@ietf.org
Date: Tue, 26 Aug 2008 18:37:02 +0200
Message-Id: <1219768622.6169.70.camel@nerts>
Mime-Version: 1.0
X-Mailer: Evolution
Subject: [imap5] My personal wishlist for an IMAP5
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: imap5-bounces@ietf.org
Errors-To: imap5-bounces@ietf.org

I'll give it a try ...

I want to point out that for client developers IMAP4's biggest problem
is not the raw complexity of the protocol.

The problem with IMAP4 is this: 

	"You have to implement your requirements anyway."

Even if the developer of the IMAP server decided not to support a
specific capability. 

It doesn't matter for your requirements: you still need to implement it
in your client.

That explains why a lot of E-mail clients have horror code: clients need
to do both too. Your user doesn't care about how poor his own IMAP
server is.

What I want most from IMAP5 is a marketing word that says: THIS set of
modern capabilities IS an IMAP5 server. Once adopted E-mail clients
could far more easily consume the modern things:

It's a guarantee for quality for the user of your E-mail client: it's
IMAP5, so it's okay.

Right now it's like this: "It's an IMAP4, it might be okay, it might be
not much better than a POP server, we don't know yet. Let's try, shall

Not good enough for an answer. You leave your user in doubt and he'll
blame it on "the device", "the computer", "the e-mail client", etc.


Remove and require QRESYNC's syntax in SELECT. No need for redundancy.
QRESYNC and CONDSTORE serve the same purpose. 

Newly written clients use QRESYNC, period.


Replace it with ESEARCH. Make ESEARCH a requirement for IMAP5

Make it possible to search multiple mailboxes (and find a solution for
the UIDs if you do, perhaps always send the mailbox name as a token in
front of the UID).


Require it in IMAP5


 * Get rid of that silly delimiter stuff. Who came up with that anyway??

 * Make LIST-EXT mandatory

 * Add counts

 * Make it possible to fetch n levels of hierarchy in the tree (I know
   about %, but I also want to fetch a few hierarchies with just one


Kill it after torturing it


Kill it after torturing it twice

Folder removals

Add clarity about subscription state after removal of a folder without
first unsubscribing it.

Counts in LIST:

Every E-mail client needs to show an up-to-date count of each folder.

I know a lot of IMAP server developers say that they can't make LIST
fast if they need to add counts. But guess what E-mail client developers
have to do "anyway"? If they don't have the counts, they will do STATUS
on each folder. 

Yes they will.

It's in their UI requirements. 

Yes the user wants these counts instantly.

Due to having to call a bunch of STATUSes it's noticeable by the user
that the counts are not immediate. Not good. Makes IMAP look sluggish.

The server has an ENTIRE DAY to count. My E-mail client must satisfy the
user NOW.

Unsolicited events

The problem with unsolicited events in IMAP4 is that they are
underspecified. As a result it seems that each IMAP server behaves

The net result of that is that most E-mail client developers simply
ignore most unsolicited events. Except the ones that can't be ignored
(EXPUNGE for example).

You can't rely on something that is not sufficiently specified and of
which the behaviour differs per IMAP server.

NOTIFY and IDLE are heading in the right direction (they specify the
events far more detailed, so it makes IMAP more reliable for the client

Unsolicited LIST events must also include the counts of the folders


Kill it. It makes tracking sequence numbers required. Replace it with
QRESYNC's VANISHED: Less complex, more reliable. 

Add the mailbox name to VANISHED too, this makes it possible to tell us
about expunges in mailboxes that are not selected.


Require QRESYNC in IMAP5

Make SELECT-ing folders less necessary (multi-span searches, VANISHED
with the mailbox name, etc).


Kill it if LIST does it already


The number is useless. What the user perceives as "unseen" equals to:

	-> Not deleted and not read

Not read and yet deleted means "spam" (you don't count that as unseen in
the user interface). If not for ESEARCH there's currently no way to get
the right unseen count.

Most E-mail clients are counting the unseen after synchronizing (after
fetching all the flags of all the messages) for that reason.

Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 

imap5 mailing list