I've given up on the IMAP5 mailing list going endlessly around in circles, though I'm definitely going to read through the backlogs and remind myself again what everyone spoke about, because there was some excellent discussion.
So - I will build something and prove that it's good by showing improved user experiences. And I'm happy to keep talking here on these mailing lists too. I've started a wiki page: http://imapwiki.org/ReplacementProtocol and plan to blog about what I'm doing on our own (Opera's) blogging platform, to practice using it: http://my.opera.com/brongondwana/blog/ I plan to make on a protocol which can replace IMAP in most of its current uses. I want to get (at least) two working server implementations, and two working clients. I have at least in-principle support from enough project maintainers to do that. My strong philosophical ideals are: * Simple to build clients - morons welcome. If it's not clear the right way to do something to someone just reading a protocol dump, we haven't done a good enough job. We can't expect you to read 30 RFCs and resolve their conflicts yourself before starting coding, and we won't insult you if you didn't get it right. Where there is necessary complexity, the server authors bear the brunt. * Server side data model compatible with IMAP4 + extensions; we need to be able to co-exist. * Handle disconnection more gracefully - able to cheaply resync state (I plan to reuse the QRESYNC/CONDSTORE logic here - the model is sane). Getting reliable updates on mailbox state changes should not require a continuous connection. * Easy to proxy - regular syntax (UTF-8 for all communications where possible, but won't screw about trying to "fix" MIME - message file format will remain unchanged) * NO MAGIC - everything is explicitly requested. No UNSELECT/CLOSE/ SELECT another mailbox special behaviours, no implicit FETCH + SET \Seen, no pre-calculated "UNSEEN X" that wasn't asked for. (This probably means some way to compose actions and fetches, but it's better than being complex and magical. Remember our friends the morons.) * COMPLETE TEST SUITE that exercises every constraint in the spec, both positive and negative constraints. An implementation which passes the tests is compliant. An implementation which doesn't is not. This is much more likely to produce inter-operable implementations than a wordy spec ... ... if the authors want inter-operability that is. Nothing can protect against a deliberate embrace and extend - though negative constraint tests (MUST NOT) should help. I would love input. I spent most of the time at FOSDEM this year talking to other people involved in email about these ideas. I quite like the mailbox model behind IMAP, but I want to address the pain points I have seen so many times over the years. Snide comments from those who don't agree with the goals are welcome too... I just won't listen to you. These goals are very important to me. Regards, Bron. -- Bron Gondwana [email protected] _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
