EXTRA session minutes - IETF102 Montreal - 19-Jul-2018 11:00-12:00 Agenda bash - no changes suggested EXISTING DOCUMENTS: =================== sieve-fcc: Ken Murchison * There are some nits from Ned on the mailing list * Suggested approach - test for fcc support for each notify type * NEXT STEPS: Poll list for WGLC after next draft sieve-specialuse: Stephan Bosch * Only outstanding work is updating IMAP-equivalent examples * NEXT STEPS: Poll list for WGLC after next draft savedate: Stephan Bosch * Only delayed because I dropped the ball * NEXT STEPS: Working group last call objectid: Bron Gondwana * Thanks to Pete Resnick's GENART review, making it much more MUSTy * General opinion in the room - unless somebody said "this will be hard for me to implement" keep everything in. * Suggestion: make thinks strict in base spec and if people need a more relaxed thing, they can propose a spec for that. * NEXT STEPS: Poll mailing list for any issues with going to all MUST. imap4rev2: Alexey Melnikov * Barry Leiba is joining as co-author and will document the elimination of non-extended responses for LIST, SEARCH, et al. * General support for making EAI/8bit be in scope - the world is moving towards that, and this is IMAP for the future, not just the now. * Need to reach out on the mailing list for people who expect this will be a problem for them! * Some discussion of use of VANISHED rather than EXPUNGED responses, and UID in unsolicited FETCH responses. General approach, more towards keying on UID rather than MSGNO. * Some things like LIST-MYRIGHTS and full CONDSTORE/QRESYNC may not be included in the "required" part of the spec, but will add a section for "recommended other extensions for servers to support". * BINARY - binary FETCH is easier than binary APPEND so maybe should just mandate FETCH as a happy middle ground. * NEXT STEPS: keep working on the list, with special focus on EAI and BINARY. PROPOSED DOCUMENTS: =================== replace: Stuart Brandt * Has already been debated on the list, and everyone is fine with it. * NEXT STEPS: call for adoption (or objections to same) on the mailing list with an eye to immediate last call. snippet: Michael Slusarz ( thanks Michael for persisting through technical difficulties to present remotely ) * Already implemented and working in Dovecot * Interest in providing things like transcriptions of attached voice messages (instead of using metadata or conversion) * Question about non-text (e.g. image) snippets - for commercial mail particularly if we define a way to extract them, they will add them to their messages! * Definitely an appetite in the room for the work * NEXT STEPS: call for adoption (or objections to same) on the mailing list with an eye to ongoing discussion about exactly how and what it should be client-id: Michael Peddemors * Proposal is a new IMAP command before authentication used to provide a token that is unique to the particular piece of client software, allowing some level of protection against password reuse (2.5 factor auth) * Was generally agreed that the identified underlying issue (knowing that the same client is connecting) is worth examining. * Would also need to be added to SUBMIT, POP3, LDAP, CalDAV, CardDAV, etc. There's already an existing draft for SUBMIT. * The name CID is confusing because it has another meaning in MIME - definitely recommend renaming the command. * Strong suggestion that SASL might be the right place for this rather than per-protocol commands. * If this belongs in SASL, then it's not in scope for EXTRA and a different home should be found for the work. * NEXT STEPS: keep discussing on extra list for now while trying to work out the correct home. There is not consensus for adopting this work in its current form. OTHER BUSINESS: =============== spam/phishing reporting: * Might be interest in a standard way to say "Block Sender/Whitelist Sender" * No concrete proposal for anything right now * NEXT STEPS: interested parties (if any) to keep talking on the list and come back if there's a proposal. createdmodseq/globalmodseq: * There's interest in keeping on talking about what this looks like * NEXT STEPS: intereseted parties to keep talking on the list and see if the discussion reaches a proposal.