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

On 03/07/2015 04:14 AM, Ladar Levison 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?

He'd make changes, but knowing Mark, they would probably not be what 
you'd expect.

IMAP 2 came after the advent of RPC mechanisms, and if Mark had wanted 
to use one, he would have.  Since I've been around IMAP, CORBA, XML-RPC, 
BEEP, "REST", and others have come into and out of vogue.  Mark didn't 
use them.  He also didn't use SMTP-style dot stuffing.

Swapping in JSON in place of s-expressions is reasonable, so maybe we'd 
see less parens and more square brackets and commas  Yet IMAP has a 
strange grammar that looks like s-expressions, parses as s-expressions, 
yet is spelled out byte for byte without free whitespace, a hallmark of 
JSON and s expressions.  So it's hard to say what Mark would have done.

IMAP had counted-length strings way before HTTP, and IMAP uses them more 
pervasively.  IMAP 2 also happened after early RPC protocols had started 
to appear.  I think if Mark had intended a non-line protocol underneath 
IMAP, again, he could have.

I recall Mark commenting once about the reality of TCP connections being 
a lot less reliable than when the protocol was invented.  If he was 
starting over, he'd have to take that into account.  I don't know how 
he'd solve it.  I don't know how I'd solve it.

The LIST and LSUB commands were a compromise nobody loves.  Mark 
commented on one occasion that he'd figured out The Right Thing, an 
s-expression notation instead of OS-style paths.  This would have helped.

Mark once said he might have implemented folders purely with flags, but 
he ran out of flag bits in messages in one of the older (pre-mbx) 
mailbox formats.  If you're trying to do archeology in this, it was in 
the context of Gmail being different than other implementations, and I 
think the discussion was on this list.

Sometimes, what others viewed as warts, Mark viewed as features.  One 
reason for this is that Mark's server supported a bunch of different 
mailbox formats with varying levels of feature support.  (No reliable 
UIDs on MH mailboxes, classic Unix mbox performance is terrible, etc.) 
Mark would oppose things that couldn't be implemented in those, so UW 
was never going to get CONDSTORE or QRESYNC support.  A MOVE command was 
routinely opposed by Mark, in part because it was essentially impossible 
for correct implementation in most of the per-file mailbox formats, but 
also because he just didn't get Trash folders.

And I thought it odd that his imapd reported all your files in your home 
directory as mailboxes, each with a single message, but that's how Mark 
wanted it (as I learned the hard way).

This is a long-winded way of saying, if Mark were creating IMAP today, 
he'd still be worrying about how to implement it on TOPS-20, just in 
case.  Because that's who he was.

Tim

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol