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

Alexey Melnikov <> Wed, 09 November 2016 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F7CA129494; Wed, 9 Nov 2016 11:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Status: No, score=-3.498 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_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 tY3QL0oT8-iW; Wed, 9 Nov 2016 11:03:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C07BA129438; Wed, 9 Nov 2016 11:03:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1478718235;; s=june2016;; bh=M5uvM1MnuT8ZZu9/jMBBfRF+WrimBGPU8buAH6o0PxE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=p6Ya06LPrAtRZB66SOCfPZQQR8cJE3fviVzzRnhgRKxMtn8VAv8+egJHyxVWoXQOVq+LQw 936s1/6BPeQZ29HHLF1MWTKqZdbJG049ZHHff4TxjySm2jRt8bBW7KhNAyr7GcfHAua+dA tlrVgSW4+lHoJP1w57S2L1FMwGnG+/U=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 9 Nov 2016 19:03:54 +0000
To: Ned Freed <>
References: <> <> <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Wed, 09 Nov 2016 19:03:36 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 09 Nov 2016 19:03:57 -0000

Hi Ned,

If this work goes forward, there is definitely some wordsmithing to do 
to address your comments. Quick answers to some of them below:

On 07/11/2016 18:05, Ned Freed wrote:
> 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.
No, the email format is unchanged.
>> 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 
> This effectively means we're replacing all of the email protocol and 
> format
> suite with the exception of SMTP.
Yes, at least this is the proposal.
>> 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.
This might be web push, but I agree that this is not clear.
>> 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.
Yes, basically the IMAP side of things.
> Which would seem to exclude SUBMIT, unless
> you're doing SUBMIT with magic folders
Most likely, yes.
> and header fields or something
> similar.
>> 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.
No, see above.
>> 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.
>                 Ned