112 lines
5.4 KiB
Plaintext
112 lines
5.4 KiB
Plaintext
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>
|