Minutes IETF102: extra
minutes-102-extra-00

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.