55 lines
2.2 KiB
Plaintext
55 lines
2.2 KiB
Plaintext
MBOX-Line: From janssen at parc.com Sat Mar 7 21:50:32 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Janssen <janssen@parc.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: <54FB3E1F.3020909@lavabitllc.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com>
|
|
<CAKHUCzzirU0YEQ02n1zEypZCvUJ+0dU0CuPxT=ZnowTk_R6jOg@mail.gmail.com>
|
|
<54FB22EB.7090707@lavabitllc.com> <8701.1425748438@parc.com>
|
|
<54FB3E1F.3020909@lavabitllc.com>
|
|
Message-ID: <25599.1425793832@parc.com>
|
|
|
|
Ladar Levison <ladar@lavabitllc.com> wrote:
|
|
|
|
> People like what they already know.
|
|
|
|
Yep.
|
|
|
|
> Myself included. Doesn't mean its the better choice.
|
|
|
|
Yep.
|
|
|
|
> A number of non-IETF blessed messaging protocols have already switched to JSON.
|
|
|
|
I'll just note that "popular" and "correct" are not synonyms.
|
|
|
|
> > Personally, I'd do everything in binary, but that's just me obsessing
|
|
> > about packet sizes. I'm thinking about designing a secure email
|
|
> > protocol built on CCNx (http://www.ccnx.org/), which provides digital
|
|
> > signatures, encryption, and router caching. There's no concept of
|
|
> > a "connection" at all, or a "mail server"; just messages. That's
|
|
> > the future.
|
|
>
|
|
> That sounds like JSON-RPC, only you've your encoding the
|
|
> requests/responses in binary instead of JSON.
|
|
|
|
CCN is a peer-to-peer broadcast content-caching protocol, so there's no
|
|
"RPC call" from a client to a specific server which then sends a
|
|
response. The difference is somewhat like point-to-point versus
|
|
packet-switched CDN; instead of encrypting the channel the messages flow
|
|
on, the messages themselves are encrypted and attached to a unique
|
|
handle, and then just "handed out to passing strangers" for them to copy
|
|
and pass on to others (this is exactly what's happening in the
|
|
implementation of an SSL-encrypted TCP connection, of course). At some
|
|
point the receiver issues a call for that particular handle (which can
|
|
be different for each message), and anyone who has a copy sends it on.
|
|
|
|
But what I'm doing is an MTA-to-MTA protocol; what you're looking at is
|
|
an MUA-MTA protocol, like IMAP. On the other hand, in my design the MUA
|
|
*is* the MTA, so perhaps there's no difference.
|
|
|
|
Bill
|
|
|