Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

"Neil Jenkins" <> Mon, 03 June 2019 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 347EC120119 for <>; Sun, 2 Jun 2019 17:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=PnT6wHeY; dkim=pass (2048-bit key) header.b=d2pS+Qu/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mdbriCZpPOxD for <>; Sun, 2 Jun 2019 17:27:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DF18120116 for <>; Sun, 2 Jun 2019 17:27:52 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 630C220D87 for <>; Sun, 2 Jun 2019 20:27:51 -0400 (EDT)
Received: from imap7 ([]) by compute6.internal (MEProxy); Sun, 02 Jun 2019 20:27:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=6R14WDB fM+tFcgxmEjbxQXYMEIi26nRVbjqkqWheWxY=; b=PnT6wHeYUdHf1YqIkFnp7gX iIY1mKXScXxMQ5ZjD35ikwzFPbv709F5sPHCYRYgSRZJZyYEvf0MfHke2ydFdUZM 4Syz6JDrRBPkcoUhk6PZ4Pzzi6bYeTxl7b1z3IJdjMcwUBsB2N6KhFzYHOvRrVoN j0Ykc4RPnckzqmEFr9lrpCE0FjgBi/FvtKkKpW0OM59x4XFJXsZbJwosUhs5x6Nu jF98FJ3C00Ehkuw5PEq+GBmQGRpjWYSzPzlBqZGMQxYto97lklg9Vrx7H21HYH5C GcRwzZjzks1d0qd+oo7PnFppVObrwcIXT3Vy4xjD4lN/IeqVksN5K8fn8aWJLeQ= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6R14WD BfM+tFcgxmEjbxQXYMEIi26nRVbjqkqWheWxY=; b=d2pS+Qu/oaN3cwZ6qtIVqy eAx3mj+IF9nKDWH52KTbLl876L/hlXmPvMlKSO6Gzr6RnZUXjVowFYWeTHEi6lRi tpM6XWI+R358B6e42mrA2+lKjjqM12Aio7jCuib8PGPyJafSCJIyM9y4kRrhczK4 aEHfrVn6PQINoO1NSHKCsR/KPyGFXGWriaxDXgfAReDHMouNDQgXpW1T4lUc2LCd u/xb9HxepRYDq05ws7lTmKZRYS8Y+J9e03KlyWLbDelpofeGgxMws6R7diEX0Gy3 2g1OSj7tuDKR8xJrLpLN+im+QTWej4Z0QdDB/4a5AUcNfuefFkS/DRfPkaxHVZvg ==
X-ME-Sender: <xms:hmn0XHCHxS-f8rbXx7icKGta0wmJo4VzSFgarUplGpPZHcbh6HWRvw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefiedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:hmn0XGGf0SbVa1mQeRAjOl2GpWUOsmGr8FzVVqOEufc9NvaaIhMEKg> <xmx:hmn0XJqm14SmaUn5T1COoqkjaZkJhgRziDghFcackDPiD1KVrMTWXw> <xmx:hmn0XO2oS47_ZwdxcFrC2Op9X6qHK-zcBIgN-WE5U4GJAVmczqrgAg> <xmx:h2n0XDEKaE1y2-lCBYSOVsRf9P6ueKIu0-1nLCoSg-o06dVQKh3uyg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A285E180091; Sun, 2 Jun 2019 20:27:50 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 03 Jun 2019 10:27:19 +1000
From: "Neil Jenkins" <>
Content-Type: multipart/alternative; boundary=b734fa22ee5f4f5bbd0ae17d43789a96
Archived-At: <>
Subject: Re: [Extra] =?utf-8?q?Barry_Leiba=27s_Discuss_on_draft-ietf-extra-im?= =?utf-8?q?ap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jun 2019 00:27:55 -0000

I must admit to having skimmed this discussion, but it seems to me that this extension is getting way over-complicated. The key here is simply to answer the question: what is this for? The only purpose of this is to provide a way for clients to get a snippet of (plain) text to shown in the mailbox listing without downloading whole body parts and expecting a fast response from the server (like fetching common headers). This is a common feature and worth making more efficient. Trying to do anything else is making things more complicated for close to zero benefit.

I would contend:
 * No server is going to implement more than one algorithm. Like with fuzzy searching, we should not specify the algorithm in the spec. Servers should be free to implement the best solution they can, which is likely to change over time as new edge cases are found and new capabilities are available (for example, skipping salutations, OCRing an image-only body, skipping broken auto-generated plain text components and generating the preview from the text/html version instead, etc.). The server should be free to choose which parts it thinks it should use to generate the preview.
 * The client either accepts the server is going to give it a good preview or it will ignore the whole capability and generate its own, at the expense of being slower and more data hungry.
 * The output is always just plain text. This is what is shown in mailbox listings as the preview in Apple Mail, Gmail, FastMail, etc. If you think an image or text/html preview is useful, I disagree, but regardless that should be a different spec rather than overcomplicating one that solves an actual use case today. (To be clear, I think the spec already says this, but some of the comments in this thread seemed to indicate to me people thought you might want different typed outputs in the future).
 * (Perhaps controversial but…) If the server offers the capability it should always have the data readily available, so the LAZY modifier is not necessary. I would expect servers that implement this to generally calculate and cache a preview on delivery. If it's going to take a while, the benefit to the client is much less and it might as well just calculate its own. That way the client only has two code paths (server-preview or client-preview) rather than three (server delayed preview as well).

In the JMAP Mail spec, we simply specify the following for the equivalent property:

*preview*: `String`
*A plain text fragment of the message body. This is intended to be shown as a preview line on a mailbox listing, and may be truncated when shown. The server may choose which part of the message to include in the preview; skipping quoted sections and salutations and collapsing white-space can result in a more useful preview.**
*This MUST NOT be more than 256 characters in length.*