[imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

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
  [e-mail]