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

