MBOX-Line: From janssen at parc.com Sat Mar 7 09:13:58 2015 To: imap-protocol@u.washington.edu From: Bill Janssen 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> <54FB22EB.7090707@lavabitllc.com> Message-ID: <8701.1425748438@parc.com> Ladar Levison 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