35 lines
1.6 KiB
Plaintext
35 lines
1.6 KiB
Plaintext
MBOX-Line: From Pidgeot18 at verizon.net Sat Mar 7 11:25:45 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Joshua Cranmer <Pidgeot18@verizon.net>
|
|
Date: Fri Jun 8 12:34:53 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: <54FB50B9.8010009@verizon.net>
|
|
|
|
On 3/7/2015 6: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?
|
|
|
|
If Mark was redesigning IMAP today, I imagine it would end up looking
|
|
more or less like IMAP looks today with the biggest changes being some
|
|
IMAP extensions being mandatory and the entire protocol (except message
|
|
literals) being UTF-8.
|
|
|
|
From reading his messages in this mailing list, he would focus on
|
|
supporting use cases of clients, but primarily what he thinks a "good"
|
|
IMAP client looks like--unlike many others here, he was fully insistent
|
|
on message sequence numbers being the only right way to do things. A
|
|
stateful, line-based protocol would be far simpler for clients to
|
|
implement (particularly since I also get the impression that he would
|
|
have eschewed needing to use several layers of frameworks).
|
|
|
|
--
|
|
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
|
|
|
|
|