MBOX-Line: From ladar at lavabitllc.com Sat Mar 7 10:06:23 2015 To: imap-protocol@u.washington.edu From: Ladar Levison 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> <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: