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.