[Extra] Minutes for today's session uploaded

"Bron Gondwana" <brong@fastmailteam.com> Mon, 18 November 2019 09:39 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6FCEE120018 for <extra@ietfa.amsl.com>; Mon, 18 Nov 2019 01:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=n5wuCPMg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C89fOplH
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ba67g_xp_R9k for <extra@ietfa.amsl.com>; Mon, 18 Nov 2019 01:39:34 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5B11208A9 for <extra@ietf.org>; Mon, 18 Nov 2019 01:39:33 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2442722451 for <extra@ietf.org>; Mon, 18 Nov 2019 04:39:33 -0500 (EST)
Received: from imap99 ([]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 04:39:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=Js1cpsDRirBesFYwusPUesvhUFumZxQFMGFdAeg I14A=; b=n5wuCPMgy/k+BYkbQ3awhWLRlIky58368qceF8qSOuHV11QxJxtIiIR Vw+1AQhdAWFHVPIRVrUTiXxPDpDJHuZxetFRKiI1K1tB8JNiLNr06o21KguINZND 9iSlBd3v7je3AS8CBGkqn366MU0MVR2473iv62un3WmAlNwIGIp/3b7Y/mgkiHco njPlpv+rO/KjXQyoChwU9gASevuQaODl+nYNxzSWnxBRgGhJjnZoXRYdgdIsY6Rs 1rUihTZ+Y2ZiKFwxBMY6/OluwQEbudiFT8U1cNZzC7cnsCg1DDFyP9ASWYdZtjOq BOGtYxMSBItGfi+3RNfBs4o3WQ3azGA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Js1cpsDRirBesFYwusPUesvhUFumZ xQFMGFdAegI14A=; b=C89fOplHGw0hwR8Js/x8N+QgrG8cjaHUkpptlmsTpHB9O RjPNKQ8wefQ1y8kGPPIBw9LaTbYoz/tOFRbvO/MgktzDdPpvqzpjriic2SlTe92v sdKiqqDxMcwHzO38Puv6fiTb3nngJeTQAUQiJ6BB1uzgEhccutbo8cYAtLjNzaN5 niy1c4LdtT6xF5Nw65kX5+Z5lhTqGrsI8YXjIyOC6arHKE8XxN4xQr09iHlHFcUa +8adAJvbTp68tI3GBPrn7Z9WOLSBftXy+al9ZXO9osqxapjA655IoVi4nAaZ6zX+ D2B/RMx9Y5reBoX2xAjWSjwVO4Pidmr6pcCp7VBFA==
X-ME-Sender: <xms:02bSXetod6HSLrp82iI5PerggCrkB0typK9HA8SBpGHluo4vg3NRFw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeghedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:02bSXVEtzs49yyM6umzCHt9oIe8w5sCfzdRTknpKgRyKBFNaoztsRw> <xmx:02bSXYe7HfMB2HhT8yP9vjEjsxMEGaaQpbenTNwyOZ7zBCy4HxklTw> <xmx:02bSXRt6j-QE9RXa8R5-7lzrLYPqcmrBvD3hlHlgmDshXO8IClMWmQ> <xmx:1WbSXYfabrrBooPXKWju2ODuPUtC5rt1RIcsR3NGD80p1wojiLujzA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B978E324AAD; Mon, 18 Nov 2019 04:39:31 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <f8c60b4b-d18f-4c7f-993b-2d8a27d51f70@dogfood.fastmail.com>
Date: Mon, 18 Nov 2019 20:38:45 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: extra@ietf.org
Content-Type: multipart/alternative; boundary=fc2801e192464f019ec3cdc05f3301d9
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/XV4LEwS0z2d74GoDk1RgY625Se0>
Subject: [Extra] Minutes for today's session uploaded
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: Mon, 18 Nov 2019 09:39:36 -0000

Hi All,

The minutes for today's session have been uploaded to the datatracker, and are included in this email for your convenience.

Please check the ACTIONS section in particular for anything you need to do.



IETF106 EXTRA WORKING GROUP - Singapore 2019-11-18, 14:30-15:30


Welcome, Notewell, Bluesheets, Agenda bashing: 5m
Current Drafts:
* fetch-preview: 10m
* imap4rev2: 20m
* quota: 15m
Milestone review: 5m
Any other business: 5m


** work with Barry to update IMAP4REV2**
** consider both **https://datatracker.ietf.org/doc/minutes-104-extra/** notes and this set of minutes to see decisions made (and updated)**
** work with Alexey to update IMAP4REV2**
** send argument in favour of OBJECTID to the list**
** consider ANNOTATION-STORAGE with quota**
** update milestones**
** update wording of PREVIEW to have client request mediatypes**
** upload EAI Sieve draft*


== preview

* Contention: client can't have any idea what algorithm is best, so server should choose the algorithm

* From Dovecot perspective - have clients who want to be able to fetch image previews and show them
* Particularly valuable on something like a dashboard where just a couple of emails are showed.
* Also valuable where payload is encrypted and includes a fuzzy image showing enough to be useful to client "click on this to decrypt and see the actual content".

* Ahh, now I see your use case!
* Sounds like what you want is media types (e.g. Accept) rather than algorithms.

* Do you want RFC5259 CONVERT?

* That doesn't do what we actually need
* Don't want every client asking for a different format - server will produce ONE preview of text or image type and cache that

* Appears that the consensus of the room is to change the mechanism to be content types instead of algorithms, but have text/plain be the initial supported option.
* Behaviour will be same as now, just a different format.

* do we need to define a different text/? format for this so we don't block other use of text/plain?
* also: do we need a way to discover what formats a server supports, since it won't be in capabilities

* clients will just send a query regardless of server support probably, easier to just leave it unspecified and see what the server will spit back

* Should just have PREVIEW in the capabilities, no need to have a discovery mechanism, just specify the types you're willing to accept and server will spit out what it wants.

* This is a major change which will require IESG review again
* But we can do it quickly. Back to the working group, quick WGLC, done.

ACTION: Michael to get new draft done with updated wording

== imap4rev2

* should we deprecate or just remove FETCH RFC822.*?

* Let's just delete it, likewise "SEARCH NEW". If your client requests IMAP4REV2 it's opting in to the removals, and should strip them from its code.

* Good - goal is to make all the bits that are in both rev1 and rev2 work the same, but the compatability path is servers supporting both, not that clients should be able to keep crappy old stuff once opting up.

* Extended LIST still needs wordsmithing, will meet with Alexey on Friday morning and work on it

* BODYSTRUCTURE needs more examples, it's a common cause of bugs
* LIST multiple patterns is OUT
* Binary fetch only leaf nodes has issues with message/global, more research required

Long discussion on search - I didn't capture all the names of people who spoke on this, but the final proposal is:

* SEARCH without modifier works like in rev1 (heuristic)
* SEARCH FUZZY always does fuzzy matching
* add a new SEARCH SUBSTRING modifier which forces the server to use substring matching.
* The server MAY reply "NO" to a SUBSTRING search.
* We need to define an extended response code for that [SUBSTRING-SEARCH-NOT-AVAILABLE] or whatever. Can do same for FUZZY if that's not supported on a field.

* could also have SEARCH REGEX modifier. Room expressed suitable disgust.

* STATUS DELETED - yes, easy for everyone to add
* Want to do last call before Christmas!

* I'd really like to see OBJECTID included, it's very valuable.
* There's a degenerate algorithm which can be used which doesn't give you all the benefits, it's:
- MAILBOXID: digest(mboxname,uidvalidity)
- EMAILID: digest(mboxname,uidvalidity,uid)
* This is RFC compliant, but doesn't give any benefits. There's no hard requirement that same data has same ID after a rename/copy, only that same ID is never reused for different data.

* OBJECTID is needed for JMAP too

* Not entirely opposed, despite own server not supporting it
* make your case on the mailing list and make it quick!

ACTION: Bron to make case for OBJECTID on the list
ACTION: Alexey and Barry to update doc this week and send for WGLC

== quotabis

* do we want to add ANNOTATION-STORAGE as a separate type?
* is 32 bits enough for each field?
* should we redefine STORAGE in octets instead of koctets?

* feel free to make a case, but these all seem sensible from the numbers we have
* need to make a good case to break backwards compat
* more reviews please!
* plan to address this after imap4rev2 is done

* yeah, I accept all the above - I'll think about ANNOTATION-STORAGE

ACTION: people to review the draft
ACTION: Bron to consider ANNOTATION-STORAGE and whether it makes sense

== Milestones

* imap4rev2 - Dec 2019
* quota - Feb 2020
* charter review - Apr 2020
* eai sieve - May 2020

* will have more time for EAI after quota

* I think Stephan Bosch was going to do EAI Sieve

* Bonus!

ACTION: Stephan to propose EAI Sieve document
ACTION: Bron to update milestones

== Other business

Out of time! Take it to the list.

 Bron Gondwana, CEO, Fastmail Pty Ltd