MBOX-Line: From ladar at lavabitllc.com  Sat Mar  7 10:06:23 2015
To: imap-protocol@u.washington.edu
From: Ladar Levison <ladar@lavabitllc.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: <8701.1425748438@parc.com>
References: <54FAEB94.4070508@lavabitllc.com>
	<CAKHUCzzirU0YEQ02n1zEypZCvUJ+0dU0CuPxT=ZnowTk_R6jOg@mail.gmail.com>
	<54FB22EB.7090707@lavabitllc.com> <8701.1425748438@parc.com>
Message-ID: <54FB3E1F.3020909@lavabitllc.com>



On 3/7/2015 11:13 AM, Bill Janssen wrote:

> Mobility is more of a fact than a problem?  What's the particular
> problem there?  Multiple end-points?  Intermittent connections?

In my case its accessing encrypted data in general, and encrypted emails
specifically. I'm trying to decide if I should extend IMAP, or switch to
JMAP and focus on adding the new functionality to that model. Since my
eventual goal is to have others use this protocol, I'm concerned that
implementing a stateless protocol is more difficult on the server side
because it requires separating the session/mail/account logic from the
connection/requests. (I've actually done this already, with magma
protocol I referenced in the OP, so I know how painful it was.) I'm also
worried that thick client developers might not like this protocol
paradigm either, because they've never had to implement client logic
which uses it. Of course web developers would love it, but only half the
planet uses webmail.
>
>> 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.

Very true. The real difference is that requests for a single session can
arrive on different connections, at the same time. It also means storing
an identifier of using it as an auth token, that could be a cookie, or
simply a unique string that is returned by the auth request and
subsequently provided in the JSON object for each request.

>> 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.

If its any consolation, I'm not considering SOAP. My original goal was
to extend IMAP, but in a way that would translate to a JSON protocol in
the future. That's proved to be beyond my abilities, because of the
different way the two generally work. So I'll have to pick, and its
proven to be a difficult decision. Hence the OP, which sought input from
others...
>
>> 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.

People like what they already know. Myself included. Doesn't mean its
the better choice. A number of non-IETF blessed messaging protocols have
already switched to JSON. (SCIMP comes to mind, which sends JSON
messages, or their binary equivalent, using XMPP as the transport.) See
page 22 or so of this PDF:

https://silentcircle.com/sites/default/themes/silentcircle/assets/downloads/SCIMP_paper.pdf


>
> 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. As I see things, binary,
or armored is independent of the paradigm. Either would allow
requests/responses to be sent in binary, or armored using a base64.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150307/b2302636/attachment.sig>
