Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

Lyndon Nerenberg <[email protected]> Tue, 10 Mar 2015 19:23:48 -0700
Newsgroups	gmane.mail.imap.general
Message-ID	<[email protected]>
On Mar 7, 2015, at 4:14 AM, Ladar Levison <[email protected]> wrote:

> I thought this might be a good list to ask a simple, but admittedly
> subjective question: If Mark Crispin was creating IMAP from scratch, in
> the world of today, would it still be a line based protocol like it was
> with RFC3501, or would he have gone with something more stateless, like
> a JSON-RPC paradigm, like JMAP?

[ Coming in a bit late, I realize ... ]

For MRC, state was king.  And for a remote mailbox access service, he believed state was critical to building an efficient protocol.

He would have scoffed at comments about 'line' vs 'streaming' and 'text' vs 'binary' as indicative of the spewer of such nonsense being beneath contempt ;-)  What Mark got, and what so many other self-proclaimed experts in this discussion are blissfully oblivious to, is that it's the RTTs that kill an interactive protocol, and nothing else.  He firmly believed that every IMAP client developer should be forced to work behind a 1200 bps (yes, 1200) network link.  He rightly surmised that that was the only way to ensure an IMAP client would make the most efficient use of the protocol.  And I agree completely, although I did try to convince him that 9600 bps was perhaps a reasonable compromise.

Many times we talked about what the son-of-IMAP might look like.  For quite a few years I have been bouncing around an idea for an MUA access protocol.  Conceptually it is very different from IMAP, but it retains the philosophy in many ways.  I had some wonderful nights having my skin blistered by his critiques.  Fortunately there was a lot of beer at hand to quench the flames :-) The once thing we did - almost - come to agreement on was that a purely Sexpr-based protocol syntax was the right way to do it.  He always got grumpy talking about what he considered the deficiencies and compromises in the IMAP syntax that were 'forced' on him by others.  (How much of that was actually true I can't speak to.  But I know there are people still likely reading this mailing list who mightily pissed him off over what he perceived to be political manipulation of the spec for corporate gain.) (I also can't believe that he didn't just tell them to "see figure one," but there you go.)

What I took away from our conversations was this.  He thought the explosion of IMAP extensions pointed to a fundamental flaw in the design of the protocol, one that needed fixing.  He could not pin down, to his own satisfaction, what that flaw was (or flaws were); he had his own misgivings about some of the design, but he was never forthcoming to me about what he thought they were.  (He didn't want to criticize anything until he knew he could shred it with 100% validity, and that included his own work.)  But he also thought at least some of the extensions were due to pure laziness and ineptitude on the part of client writers.  (He could peel paint with that topic of conversation!)

I miss the cranky bastard, with his guns and politics and libertarian take on life :-)  We were polar opposites on the first two of those three (maybe all of them), but he respected what you had to say, even as he let loose with how he thought you were a complete idiot and did not deserve to grace a keyboard with your fingers :-)

As April approaches, I hope you will all join me in raising a glass of something uncomfortable in his memory, while you read one of his great works: http://www.ietf.org/rfc/rfc748.txt

Especially the young turks recently gracing us with their presence.  They might learn much.  Or not.

--lyndon

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
signature.asc (application/pgp-signature, 801 B)