wasm-demo/demo/ermis-f/imap-protocol/cur/1600095011.22595.mbox:2,S

73 lines
3.4 KiB
Plaintext

MBOX-Line: From tjs at psaux.com Sat Mar 7 22:56:09 2015
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun 8 12:34:54 2018
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
it be different?
In-Reply-To: <54FAEB94.4070508@lavabitllc.com>
References: <54FAEB94.4070508@lavabitllc.com>
Message-ID: <54FBF289.3010202@psaux.com>
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