| > Well, could you add instant messaging functionality to IMAP? IMAP does not reimplement XMPP, which I consider a feature. If you want instant messaging, you should use XMPP, and it's perfectly possible for a client to allow you to use both. > Can you manage multiple inboxes with one IMAP account? Yes, this is built in to the standard and every client can do this > Can you do server side threading with IMAP? Yes: http://tools.ietf.org/html/rfc5256 > Can you manage attachments and messages separately with IMAP? Admittedly not, but again do you really want to? There are separate protocols for managing files and we already have dropbox. > Can you upload attachments NOT using base64 using SMTP/IMAP? Yes: http://tools.ietf.org/html/rfc3516 > Can you use labels with IMAP? Google do it this way, but it's not standardised: https://developers.google.com/gmail/imap_extensions#access_t... There are also user-defined flags > Can you manage multiple domains under IMAP? Yes, almost every client supports multiple accounts. IMAP is a good candidate for the most often (and most badly) reinvented protocol around. There's plenty of reasons to expose parts off the current infrastructure over HTTP (Mandrill is really useful) but I think if your plan is "reinvent ALL the things" you need to be a lot clearer about what exactly is so backwards about on of the most well studied and well engineered pieces of infrastructure around. |
the problem is that it is very complex, and features are not implemented consistently accross clients. Especially the newer, or not standardized ones you listed. You know that there is something wrong when an entire slew of RFCs can be replaced with a few simple api calls.