Re: [Extra] Discussing SNIPPET

Bron Gondwana <brong@fastmailteam.com> Tue, 18 September 2018 07:54 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44C130DDE for <extra@ietfa.amsl.com>; Tue, 18 Sep 2018 00:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=I9pHmVqL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzZ5WTcH
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 JJ7nkTjrLmiz for <extra@ietfa.amsl.com>; Tue, 18 Sep 2018 00:54:00 -0700 (PDT)
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 A17D3127AC2 for <extra@ietf.org>; Tue, 18 Sep 2018 00:54:00 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9D75721E59; Tue, 18 Sep 2018 03:53:59 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 18 Sep 2018 03:53:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=I9pHmVqLgxEDyGeGTRD+eq CCeM2m/0x5ZQ294tDBbDyozFD5AE9kehIF+ECoIVw2MPuRscKxVLBBj6MajMwBVE u7Eqk01BqwRVkLkvc4keW/URFY+a1S9vPXQS8d0DgGmvdc/HT+yDO/7aPoyAwlPV KKqlqsGSUg5cc1sGE454QTyAp3GCKHaKtxFHHT/1ecGbAfqOMR8U22+23rkyiaTJ BoYDWRtt0E7FWzkufm1SOxkuG2GMBJ9WBYnOd/R7eajktVg4KXO/EDvOh7kOZs6B 5+eJ1iZfGkkx1XUUjIghCRSrj/Z1e5oWxIv7Gp18C5snVCVH9arL0boeEQs81ypQ ==
DKIM-Signature: v=1; a=rsa-sha256; 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=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=WzZ5WTcH4ZeBoMWG3gA4cd YI9d92YruX9NQQNoBl4KsDgPtNWIhMVlG7YQO9Mdze3DpyuoDRnmvfK6g3YbAG0S Nb6iP9tpZgP6pxdVSMfgZK5y0bGlQEgjMxtFGxa1lbOeRorwCVAzKCcqh0erUepU 2b3tLo/jDXm61FyfsYlqtdUAYc6CRqQQTOL0jx6X4IcnbU/zxf0iEH7QOHXqogsk UCeIBIdkZHCkRVG29pYV7K6Zec6ulyd7P1Mc0sPwcLoaJUOYk9SrzYpaO8v7dzmM v21GYl2a5JFn/whyofHUPShkFRxZLUQDKOf1n/dwrJAo+U+6GtMkHpytEn07TKUA ==
X-ME-Proxy: <xmx:Fq-gW5xlJjDTXSI_4Nq62Rup8Z8OLHqes1E-gIAfwtHzArh-OVZNnQ> <xmx:Fq-gWz15XWEXfPdLi9BlRuMqysmKnIkL9R5w7MwujN3oOMSOsugl-Q> <xmx:Fq-gW_56FfPGO8-cQ5DpC63tXRrVlLq69uJkwJ9TQQc3-9a10U_bQw> <xmx:Fq-gW-XHDiAhbHMV2Arsrn03vIhAkIWBIpKTHXSLN96byurMnhtepg> <xmx:Fq-gW2AolRnqhm_wP4Xc7cxUxm2rPVpJW-IYDqCRtJU28-nbygURIw> <xmx:F6-gW8hu283gnkvmd3a3lSAj3GYkA3gc10_K8cOu8eYDYnPwXtMweA>
X-ME-Sender: <xms:Fq-gW74bqP4gLcBjxi9NvP0hbGvPRhMBextTDqg3RyMqxQ3bX752SQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 944C1E2319; Tue, 18 Sep 2018 03:53:58 -0400 (EDT)
Message-Id: <1537257238.2278116.1511804688.496B30F1@webmail.messagingengine.com>
From: Bron Gondwana <brong@fastmailteam.com>
To: Josef Jeff Sipek <jeff.sipek@dovecot.fi>, Chris Newman <chris.newman@oracle.com>
Cc: extra@ietf.org, Michael Slusarz <michael.slusarz@open-xchange.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_153725723822781160"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-15b169d8
References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> <20180918074720.GB1384@meili>
Date: Tue, 18 Sep 2018 17:53:58 +1000
In-Reply-To: <20180918074720.GB1384@meili>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/GZ651O_YuUuYAd_1-CuBDVqyYtc>
Subject: Re: [Extra] Discussing SNIPPET
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 07:54:03 -0000

On Tue, Sep 18, 2018, at 17:47, Josef 'Jeff' Sipek wrote:
> On Mon, Sep 17, 2018 at 17:31:23 -0700, Chris Newman wrote:
>> On 17 Sep 2018, at 4:52, Bron Gondwana wrote:
> ...
>>> b) Cache Invalidation. Ho hum. Is this an immutable property? If so,>>> what happens if the server implementation changes? I'm quite
>>> happy to>>> call it "softly immutable" myself - it might not be exactly the same>>> bytes, but you can use the old version without major problems.
>> 
>> The 'softly immutable' option works for me. However, I'll propose an>> alternative so we can contrast two reasonable options. We could add
>> a way to>> fetch a FUZZY algorithm identifier for a given folder.
>> Something like:>> 
>> C: A043 STATUS blurdybloop (FUZZYALG)
>> S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0"))
>> 
>> A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is
>> immutable unless>> the FUZZYALG string changes. This has some non-trivial server
>> implications,>> but if clients really need predictable PREVIEW caching behavior,
>> this is a>> protocol model I'd be willing to implement to provide that.
> 
> For what it's worth, in Dovecot we cache the generated
> snippet/preview along> with a version number and take the 'softly immutable' approach.  For
> example, an email with body of "foobar" would turn into
> "1foobar" in the> cache file.  When a client FETCHes it, we strip the version.  We
> haven't had> the need to up the version yet, but at least in theory it should
> provide us> with a way to tweak the snippet algo and know which cached values
> are stale.
We do something similar at FastMail - we have a keyword (currently $X-ME-Annot-
2) which is a version number for the logic which generated the preview
and a couple of other keywords like $HasAttachment by parsing the
message content.
> I'm not fully caught up on the discussions here so maybe I'm missing
> something, but I was under the impression that the algo can be
> selected per> **email** so wouldn't it really have to be a FETCH * FUZZYALG?.  I
> don't quite> understand what the above STATUS accomplishes; I guess it is
> something like> a uidvalidity for snippets in a folder but I'm not convinced
> that it is> worth it.  If you want to have the latest snippet, just FETCH it.

I agree with that!  It's small enough that re-fetching isn't a big deal
if you are worried that it might be old - and the cost in roundtrips to
check the version first plus the added complexity isn't worth it.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com