[Extra] Minutes from IETF102 meeting

[Bron Gondwana <[e-mail]>]

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


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]