Subject: [Extra] Minutes for today's session uploaded

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 18 Nov 2019 20:38:45 +1100

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.

Cheers,

Bron.

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

= AGENDA

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

= ACTIONS

*Alexey:**
*
** 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)**
*
*
*
*Barry:**
*
** work with Alexey to update IMAP4REV2**
*
*
*
*Bron:**
*
** send argument in favour of OBJECTID to the list**
*
** consider ANNOTATION-STORAGE with quota**
*
** update milestones**
*
*
*
*Michael:**
*
** update wording of PREVIEW to have client request mediatypes**
*
*
*
*Stephan:**
*
** upload EAI Sieve draft*

= DETAILED NOTES

== preview

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

Michael:
* 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".

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

Alexey:
* Do you want RFC5259 CONVERT?

Michael:
* 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

Neil:
* 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.

Bron:
* 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

Pete:
* 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

Barry:
* 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.

Alexey:
* 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

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

Bron:
* 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.

Alexey:
* 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.

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

Alexey:
* BODYSTRUCTURE needs more examples, it's a common cause of bugs
* LIST multiple patterns is OUT
* LIST RETURN STATUS is IN
* 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.

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

Alexey:
* SEARCHRES is IN
* STATUS DELETED - yes, easy for everyone to add
* Want to do last call before Christmas!

Bron:
* 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)
- THREADID: EMAILID
* 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.

Neil:
* OBJECTID is needed for JMAP too

Alexey:
* 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

Bron:
* 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?

Alexey:
* 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

Bron:
* 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

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

Alexey:
* will have more time for EAI after quota

Michael:
* I think Stephan Bosch was going to do EAI Sieve

Alexey:
* 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
 [email-masked]