* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Extra Status Pages

Email mailstore and eXtensions To Revise or Amend (Active WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2017-Sep-13 —  

IETF-106 extra minutes

Session 2019-11-18 1330-1530: Orchard - Audio stream - extra chatroom


minutes-106-extra-00 minutes

          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
          * 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
          = DETAILED NOTES
          == 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
          * 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
          * 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.
          * could also have SEARCH REGEX modifier.  Room expressed suitable disgust.
          * SEARCHRES is IN
          * 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)
           - 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.
          * 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.

Generated from PyHt script /wg/extra/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -