86 lines
4.0 KiB
Plaintext
86 lines
4.0 KiB
Plaintext
MBOX-Line: From janssen at parc.com Sat Mar 7 09:13:58 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Janssen <janssen@parc.com>
|
|
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: <54FB22EB.7090707@lavabitllc.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com>
|
|
<CAKHUCzzirU0YEQ02n1zEypZCvUJ+0dU0CuPxT=ZnowTk_R6jOg@mail.gmail.com>
|
|
<54FB22EB.7090707@lavabitllc.com>
|
|
Message-ID: <8701.1425748438@parc.com>
|
|
|
|
Ladar Levison <ladar@lavabitllc.com> wrote:
|
|
|
|
> On 3/7/2015 8:34 AM, Dave Cridland wrote:
|
|
> > But in the world of today, the elephant is that the bulk of mail is
|
|
> > under the control of a handful of huge providers, and a guy working in
|
|
> > a university lab somewhere is pretty unlikely to have the chance to
|
|
> > make any kind of difference, and probably wouldn't be interested.
|
|
> > Mark, in his twenties, tended to solve practical problems that he
|
|
> > encountered, like telnet issues, roaming mail users, etc. Those
|
|
> > problems are already solved, so I suspect he'd be solving some
|
|
> > entirely different problem today, like WebRTC signaling, or practical
|
|
> > end to end crypto, or secure file sharing, or heaven only knows what.
|
|
>
|
|
> If all those big providers were using POP, and he wanted to solve a
|
|
> problem, like mobility, would he have approached it differently?
|
|
|
|
Mobility is more of a fact than a problem? What's the particular
|
|
problem there? Multiple end-points? Intermittent connections?
|
|
|
|
> From an abstract standpoint, the programming language doesn't
|
|
> matter. IMAP is a protocol that can be implemented in any language,
|
|
> which holds true for JSON protocols as well.
|
|
|
|
Well... JSON stands for "Javascript Object Notation", so Javascript
|
|
does have a bit of an alpha status there. And it's harder to parse
|
|
than S-expressions :-).
|
|
|
|
> They are simply schemes for stateless client/server interactions
|
|
> (stateless because they have to go over HTTP)
|
|
|
|
There's no intrinsic reason things that have to go over HTTP have to be
|
|
stateless; it's just a tradition that comes from the now somewhat
|
|
archaic idea in HTTP 1.0 that you close the session identifier (the TCP
|
|
connection) after each request/response pair. Sessions were almost
|
|
immediately re-defined via cookies, and many protocols over HTTP
|
|
are now stateful, using those cookies.
|
|
|
|
> and which happen to use JSON as the serialization scheme. They could
|
|
> just as easily have used SOAP/XML.
|
|
|
|
Yes. However, SOAP, as it was originally designed by Microsoft, is a
|
|
pretty (IMO) bletcherous (i.e., tasteless) and bloated attempt to funnel
|
|
DCOM calls through firewalls in a way that wouldn't be immediately
|
|
interdicted by anti-virus software. So, a LISP person wouldn't be able
|
|
to bring himself to use it (speaking as a former Lisp and RPC person).
|
|
|
|
JSON over HTTP is a somewhat (but not much) cleaner re-interpretation
|
|
of the same idea.
|
|
|
|
> I'm wondering if the future of mail protocols is to continue improving
|
|
> the line based protocols we have, or will they be replaced by something
|
|
> that is friendly to the web? Were seeing a number of vendor specific
|
|
> mail protocols already, and I'm wondering if convergence is in our
|
|
> future? In other words, if someone were to start working on a new
|
|
> protocol today, should they focus on the old line based scheme, or
|
|
> switch to the newer stateless, JSON paradigm common to the web?
|
|
|
|
JSON is just a Javascript convenience. It's not a particularly
|
|
efficient way of sending data over the network. I think your question
|
|
about line-based protocols is a good one, but the IETF still leans
|
|
towards observable-text based protocols. So, if you wanted to design
|
|
an email protocol that would be blessed by the IETF, using a text-based
|
|
"line" protocol isn't a bad idea.
|
|
|
|
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.
|
|
|
|
Bill
|
|
|