73 lines
3.4 KiB
Plaintext
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
|
|
|
|
|