Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap)
Neil Jenkins <neilj@fastmail.com> Tue, 07 February 2017 02:52 UTC
Return-Path: <neilj@fastmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5911297E8; Mon, 6 Feb 2017 18:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.718
X-Spam-Level:
X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.com header.b=WzNOwq0e; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=TveEP980
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLgku-b3pa3t; Mon, 6 Feb 2017 18:52:50 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EF21297E7; Mon, 6 Feb 2017 18:52:49 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 69AA1206E0; Mon, 6 Feb 2017 21:52:49 -0500 (EST)
Received: from betaweb1 ([10.202.2.10]) by compute1.internal (MEProxy); Mon, 06 Feb 2017 21:52:49 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=QGiY8NT5nby9k92Yy7lCTrcLE+ I=; b=WzNOwq0ey2azEsXdeau6G7j+xhgG7o7KDpq5tSD/fTfBAcILt2NyI/NxV3 6KhRc+1ErLomBqjRON2nZvg+NZM793dL/gXCM2J+Ygv6+A9Y/Za31dInIsmx+equ WBMiFnNEx1m9l9UjioL6hXQcMqmLgKuEp5+4HAn9GqDTPdWhA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=QG iY8NT5nby9k92Yy7lCTrcLE+I=; b=TveEP980PkImJgW8Qa8qw+qoOuJw94Nowh B9bXQYUX5SEtddu2T2uCQKkNU4nrGkUY3jvAjA8ReenRfJ540wGJ9p4XXy9+RKRE F2nhqVY4zGgfvYlxl89y+vrWfLNgCTm39DhWJhmybcDQ7KthjcY37xZkQHSTLtjA nzWbaK1Tg=
X-ME-Sender: <xms:gTaZWCgpagNbqcI1fb_wrWHrL19UZXkUeYqcFewzkonM1amyoWypkQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 28085E23C8; Mon, 6 Feb 2017 21:52:49 -0500 (EST)
Message-Id: <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com>
From: Neil Jenkins <neilj@fastmail.com>
To: dcrocker@bbiw.net, Alexey Melnikov <alexey.melnikov@isode.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_148643596923140630"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-fdb7c997
Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap)
In-Reply-To: <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net>
Date: Tue, 07 Feb 2017 13:52:49 +1100
References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jptLUpPizBx-7mTWG4d8Hq5zIkw>
Cc: jmap@ietf.org, ietf@ietf.org, iesg <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 02:52:52 -0000
Hi I'll try to clarify a few of these points. *Message representation* JMAP defines a JSON structure that represents in a consistent and structured way all the information that the vast majority of clients need from an RFC5322 message. The server deals with the complexities of MIME, encoding issues, parsing headers etc. The intention is that the server will still operate with RFC5322 messages for storage and certainly transmission; the JSON representation is not intended to replace RFC5322, just relieve client authors from having to deal with it. Clients can also just fetch the properties they need, reducing bandwidth overhead. Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed. *Industry need* A number of proprietary protocols have been popping up as alternatives to IMAP, which all also have their own JSON representation of message objects. Here are a few examples, the latter two being from whole companies that formed just to try to help people not have to deal with IMAP: * Gmail[1] * Outlook[2] * Nylas[3] * Context.io[4] In addition, we’re seeing most new mobile email clients proxy everything via their own server rather than talking directly to the user’s mail store. Examples include Mailbox (now defunct), Alto, Outlook and Newton. This is bad for security and privacy, and also bad for the client authors as they have to run server infrastructure in addition to just building their clients. Despite not only being proprietary but patented (and expensive!), ActiveSync has seen a big increase in adoption, and not just with Microsoft servers, due to its better support for mobile environments and ease of setup (one login for mail receive/send, contacts and calendars). *Protocol vs representation* JMAP is a protocol. It primarily defines a way of syncing data objects in a network-efficient, developer friendly way. Objects are defined to represent mailboxes, threads and messages in a consistent manner. These are encoded as JSON for transmission over HTTPS. *Message submission* > There is no justification given for this approach. For each > activity, there needs to be a clear and solid need documented, based > on actual industry activities or at least industry statements. > Besides clarifying /what/ needs doing, it should serve to indicate > likely industry uptake after the work is done. This *is* based on industry statements. This is a very common support problem we see here at FastMail, and from our conversations with other mailbox vendors, we don't think this is just us. *Flood control* In IMAP, suppose you have a mailbox with 1,000,000 messages in it selected, and another client expunges the lot. You get * 1 EXPUNGE sent to you 1 million times (and you don't even know how many you are going to receive); the only option is to drop the connection if it gets too much. By flood control, we mean the client can ensure it does not get flooded with data, especially important on low-bandwidth connections like many mobile networks and in developing countries. Reducing data usage is of course vital for saving battery, another key concern for mobile. Similarly, the server has well defined ways of rate limiting the amount of work the client can ask it to do to ensure it too does not get flooded and either accidentally or deliberately DOSed by client requests. *Why HTTP underneath* The short answer is it’s good enough, widely understood and it’s by far the easiest thing for developers to adopt. There’s support in basically all OSes and programming languages. It’s easy to read and debug. HTTP doesn’t tend to run into firewall issues, and is so commonly used it has integrations which can help with optimisation (for example, iOS has built-in support for optimising radio usage by batching HTTP calls from different apps where possible, which their mail team have told us they would like to be able to use). This isn’t an innate advantage of HTTP, but rather an advantage of its ubiquity. *Statelessness* The protocol does not make use of any connection persistence to the server. HTTPS may establish this underneath, but the protocol on top is agnostic to it. Each request to the server contains an authorisation token (in the Authorization header) to identify and authenticate the request. Neil. Links: 1. https://developers.google.com/gmail/api/v1/reference/ 2. https://msdn.microsoft.com/office/office365/APi/mail-rest-operations 3. https://nylas.com/cloud/docs 4. https://context.io/docs/lite
- Re: WG Review: JSON Mail Access Protocol (jmap) Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Adrien de Croy
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Phillip Hallam-Baker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jenkins
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Gren Elliot
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Randy Bush
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Gren Elliot
- Fwd: Re: [Jmap] WG Review: JSON Mail Access Proto… Gren Elliot
- Re: [Jmap] service discovery, was WG Review: JSON… John Levine
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Dave Crocker
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Randy Bush
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… John C Klensin
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Adrien de Croy
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jhaveri
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Gren Elliot
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Joe Hildebrand
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jenkins
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Yoav Nir
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Cridland
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Acc… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Andrew Sullivan
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Spencer Dawkins at IETF
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Ted Hardie
- Re: WG Review: JSON Mail Access Protocol (jmap) -… John Levine
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Pete Resnick
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Ted Lemon
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Dave Crocker
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… ned+ietf
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John Levine
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Phillip Hallam-Baker
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Cridland
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… John C Klensin
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Cridland
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Cridland
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… ned+ietf
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin