Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Mon, Feb 13, 2012 at 10:56:49AM +1300, Adrien de Croy wrote:
> Finally, one of the things I am keen to see disappear with IMAP5
> (for want of a better name) is the requirement for clients, admins
> etc to deploy multiple protocols - e.g. allow submission in IMAP.
> This is because it's frankly a large (and should be unnecessary)
> admin burden trying to support 2 protocols for mail (e.g. SMTP +
> POP3/IMAP4).  Mail users don't understand the significance, they
> just submit support tickets because they can retrieve mail but not
> send.  Firewalls block ports, ISPs intercept / block port 25 (NZ
> largest ISP does this), multiple protocols = multiple realms for
> credentials, multiple implementations of authentication and
> authorization etc.

Absolutely agree.  There has to be a way to do basic "client
wants to upload a message to Sent (possibly upload it to
Drafts first and then move it to Sent, with a copy going
out to the destination too) within the one protocol.  If
you're doing something more fancy, there's still SMTP.

> Having to have another protocol to implement to get notifications
> back probably over another channel etc makes this issue worse not
> better.

Similarly, there needs to be a way to do notifications in-protocol.
I still think that being compatible with an external protocol as
well is good.  Either way the notification should need to be nothing
more than a new HIGHESTMODSEQ value from which the client can update
whichever views it's interested in.

To reduce roundtrips, it would be nice to register a view on which
you want updates pushed rather than just getting a new modseq and
having to ask for the updates... but that's a minor optimisation
compared to having to run a "STATUS loop" over all your folders or
open hundreds of separate TCP connections to get information.

Bron.