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

Ned Freed <> Mon, 07 November 2016 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4B2C12947A; Mon, 7 Nov 2016 10:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2aBt7MqfNlF5; Mon, 7 Nov 2016 10:23:44 -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 4CB07124281; Mon, 7 Nov 2016 10:23:44 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Mon, 7 Nov 2016 10:18:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mauve; t=1478542720; bh=prpJn4gqbnbtpwq8290digrcU9xyLd4pxYaJrOt44Cg=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=MV2OKVw9Lo2nKx0VroQUUrmLlOIr8lL8+/ieAK8NlBa8l04kcSz4fRSrpdfcHRqCu 35M3y5BEjG0D1IhXkDlWxL3yNPV2t9ZpVRNPgS5BGSs8wMjfbv6CP5Z1f/BKtSKsGP lwdtSOHzkgG6teUl+mEdEN1GAC9nYpAtfKaFFtt8=
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 <>; Mon, 07 Nov 2016 10:18:38 -0800 (PST)
Message-id: <>
Date: Mon, 07 Nov 2016 10:05:06 -0800
From: Ned Freed <>
In-reply-to: "Your message dated Mon, 07 Nov 2016 17:31:31 +0000" <>
References: <> <>
To: Alexey Melnikov <>
Archived-At: <>
Cc:, "''" <>
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: Mon, 07 Nov 2016 18:23:46 -0000

Without getting into whether or not this is in general a good idea, I want to
note that the proposal as written is self-contradictory, making it very
difficult to evaluate. In particular:

> Name:    JSON Mail Access Protocol
> Acronym: jmap
> Area:    Applications and Real-Time Area (art)

> Charter for Working Group

> Many companies and projects are developing their own JSON based
> representations of email which are proprietary, non-standard, and
> incompatible with each other. These protocols are proliferating due
> to existing standards being insufficient or poorly suited to the
> environments they are operating in, particularly mobile and webmail.

"Representation of email" would seem to imply that we're talking about a new
message format.

> The JMAP working group will specify an mechanism to allow clients to
> both view and send email from a server over a single stateless HTTPS
> channel with minimal round trips.

And now we appear to be talking about a replacment for both IMAP and SUBMIT.
This effectively means we're replacing all of the email protocol and format
suite with the exception of SMTP.

> The protocol will support
> out-of-band signaling of changes, and will give mobile clients
> significant benefits in terms of battery life and network usage.

And now we appear to be talking about server->client synchronization, which
is, in standards terms at least, new.

> The use of multiple protocols to perform actions within a single
> application creates significant support challenges, as users may get a
> variety of partial failure modes (for example, can receive email, but
> can not send new messages).  This is further exacerbated if the
> different protocols are authenticated separately.

So we're clearly aiming to replace multiple protocols here.

> The work of this group is limited to developing a protocol for a client
> synchronising data with a server.

Whoops! Now we're talking we're limiting ourselves to synchronization of
the client with the server. Which would seem to exclude SUBMIT, unless
you're doing SUBMIT with magic folders and header fields or something

> Any server-to-server issues or
> end-to-end encryption of messages are out of scope for this working
> group.

If you're talking about a new message format, you're going to have
to deal with end-to-end encryption issues whether you like it or not, either
by changing SMTP as well so that message in this new format can in fact
be transmitted end-to-end, by defining an encapsulation format, by allowing
servers to perform gateways, etc.

> The working group will coordinate with the Security Area on credential
> management and authentication.

Again, if you're talking about a new message format, this isn't going
to be remotely adequate.

> Input to working group discussions shall include:

> - Internet Message Format
> [RFC 5322]

This also would seem to imply the message format is in play.

> [RFC 7162]

> - Collection Synchronisation for WebDav
> [RFC 6578]

> - LEMONADE and experiences from adoption of its output
> []

> [RFC 4409]

And SUBMIT is in play.

> [RFC 4468]

Again, I'm not prepared to offer an opinion as to whether or not this whole
thing is a good idea. But I will say that effectively replacing the entire
email protocol suite - which is entirely consistent with what's  been said here
- would at a minimum be a tremendous amount of work requiring a tremendous
amount of justification, and what's in this propsoal doesn't come close.