[imap5] My personal wishlist for an IMAP5

[Philip Van Hoof <[e-mail]>]

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
we?!"

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.


CONDSTORE:
----------

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.


SEARCH:
-------

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).

THREAD:
-------

Require it in IMAP5


LIST: 
-----

 * 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
   command)


NAMESPACE:
----------

Kill it after torturing it

LSUB:
-----

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
different.

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
developer).

Unsolicited LIST events must also include the counts of the folders


Unsolicited EXPUNGE & XGWMOVE
-----------------------------

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.


SELECT:
-------

Require QRESYNC in IMAP5

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

STATUS
------

Kill it if LIST does it already

UNSEEN in STATUS (in LIST)
--------------------------

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 
http://pvanhoof.be/blog
http://codeminded.be




_______________________________________________
imap5 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/imap5