A Replacement Protocol

IMAP has been extended by very many RFCs, of which servers implement random parts, and clients either have to special case all of them, or just use the most simplistic protocol. The "IMAP5" mailing list didn't get anywhere.

I think it's time to get serious about an IMAP replacement.

The eventual goal here is "be compelling enough that the effort required to change is worthwhile". This includes server implementors, client implementors, and end users. If we're going to make an open protocol to replace IMAP, it had better give everyone a reason to switch.

I would like to use this page to store our discussion. I will also be blogging about it on MyOpera

Requirements:

Some areas of interest:

LIST/LSUB/Special-Use:

Message management:

Transactions:

Implicit vs Explicit:

Stateless Operation:

Notifications:

Bandwidth-wise:

Consistent Synax:

A lot of these is the CISC vs RISC debate. I believe it's better to compose your messages from client to server and server to client out of groups of small "lego bricks" each of which expresses one thing succinctly rather than pre-formed "fighter wing" shapes. The biggest lack I see in the current email landscape is that that IMAP clients wind up doing convoluted things to support all the possible combinations of multiple RFCs out there, or just giving up and supporting a very simple profile, because that way they don't need multiple codepaths.

If we can agree on a more expressive communication protocol between the clients and servers, I don't think we need to change the model at either end very far.

The goal, again, is to provide a complelling _experience_ for users of this protocol - that accessing your email via this protocol is a better, more reliable, more predictable experience. That's how we win hearts and minds, and make others want to implement the protocl

Thanks,

Bron.

ReplacementProtocol (last edited 2013-02-05 18:39:40 by pai34-5-88-176-168-156)