Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

Ned Freed <> Wed, 09 November 2016 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1B001294AD; Wed, 9 Nov 2016 07:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 78tI6fPrit95; Wed, 9 Nov 2016 07:37:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E041A1295C0; Wed, 9 Nov 2016 07:37:50 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Wed, 9 Nov 2016 07:32:42 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"; format="flowed"
Received: from by (PMDF V6.1-1 #35243) id <>; Wed, 09 Nov 2016 07:32:38 -0800 (PST)
Message-id: <>
Date: Wed, 09 Nov 2016 07:15:41 -0800
From: Ned Freed <>
In-reply-to: "Your message dated Tue, 08 Nov 2016 10:15:31 -0700" <>
References: <> <> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <>
To: Doug Royer <>
Archived-At: <>
Cc: John C Klensin <>, Alexey Melnikov <>,, "''" <>
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IMAP extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Nov 2016 15:37:52 -0000

> > These are just questions, not opposition, but the answers should
> > probably be clear in any charter or chartering effort.
> >
> > (1) We've had a long history of variations on The Format to End
> > All Formats, none of which have lasted a very long time.  I
> > think JSON is better than most, but, if yet another wonderful
> > format shows up in a few years and takes over, is it worth
> > thinking now about what a transition plan would look like?

> > (2) Some of us believe, ... because they operate
> > in plain text, ...

> I thought JSON was 7-bit, and required encoding to use 8-bit data portable.

JSON is almost always UTF-8. So no, it's unabashedly 8-bit. But so is 
the overwhelming major of the existing email infrastructure, so this is 
a wash.

> So, if I am correct, then JSON is not a gain when it comes to non-text data?

This is also a wash.

Binary MIME has been around for almost 25 years. SMTP was extended to
handle it not long after it was defined. And note that it's entirely
possible to use binary MIME only on SUBMIT and not depend on the
rest of the infrastructure handling it.

IMAP has had the ability to transfer parts in binary for a long time. And
IMAP also offers the ability to decode and transfer a encoded part on
the server side.

JSON doesn't support binary, but there are various extensions that do.

> > (3) ...  Seems
> > to me that would promote much more compatibility and flexibility.

> The complexity of the requests and replies are the issue. If its mostly
> converting IMAP to JSON, the same problems are going to exist.

Yes and no. Part of the problem with IMAP is that it was designed for
a very different sort of client than what we have now. (I note that the
problem SMTP is intended to solve hasn't changed nearly as much.) Getting
rid of historical baggage will definitely simplify things.

IMAP also uses an unnnecessarily large number of format variants.

OTOH, there's absolutely no doubt that there's considerable intrinisic
complexity in the message access space. Especially given the desire to
push more and more of the problem to the server.

On the flip side, basing things on HTTPS adds an enormous amount of inherent
complexity. But most of that complexity is hidden from the majority of
developers, who won't code HTTPS support directly, preferring instead to
use any one of the bazillion libraries out there that does it all for you.

My guestimate is that - and here I'm speaking only of the message access space
- that a HTTPS/JSON approach wins in terms of effective implementation
complexity, although it is far from clear to me by how much.