EXTRA MINUTES - IETF103 BANGKOK - 8 NOV 2018 Existing docs --- savedate: * comments needed in response to IESG tracker * don't believe anything else is required ACTION: Alexey will progress sieve-fcc: * ABNF suggests that tagged params have other parameters still, wordsmithing required * Alexey has suggested a change ACTION: Bron to talk with Ken about fixing wording sieve-special-use: * ready to progress ACTION: Jiankang to submit for publication imap4rev2: * needs more examples, particularly around BODYSTRUCTURE * also clearer wording for these difficult parts * needs examples for bodypart.MIME and bodypart.HEADER * suggestion to look at unofficial IMAP wiki for useful words * Q: is it legit to require only UTF8? Not for search, which needs to be able to match charset of data, but everything else is UTF8 only in imap4rev2 * open issues - all to be asked on the mailing list! ACTION: Bron to start 1 thread per open issue on the list ACTION: Bron to email other IMAP-related lists asking for input from client and server implementations about these issues TIMELINE: expect to be done by March (submit for publication pre-Prague) preview: * debate over 200 vs 255 * good to align with JMAP so servers can store one value * other than this issue, take to working group last call ACTION: Bron to email list with 200 vs 255 question. 64bit: * 53 bits is plenty * Nobody is clamouring for this or needs it * The couple of places (STATUS=SIZE and quota) will handle 64 bit separately ACTION: leave it dead Group next steps: --- * General support for keeping a group around to deal with email stuff, so we will keep operating while there's work trickling in * Document for sieve and EAI -> Stephan will have a go at it * QUOTA-BIS - Alexey has a start - happy to give to another editor * SMTP-related work: - options - recharter this group or spin up a new one - replace RFC532[12] with new version which include errata an replace 82[12] as "INTERNET STANDARD" docs. - MIME specs as well? - new WG vs recharter should go to the list. - in theory only a couple of months' work, but could easily go into the weeds and fail as the last couple of attempts have. ACTION: Bron to email list regarding sieve-EAI proposal ACTION: Bron to email list with request for author for QUOTA-BIS ACTION: Bron to email list regarding recharter vs new SMTP group Discussion of "scaring off new people" --- * CLIENTID proposal at Montreal led to potential contributors not engaging. * Were we too abrasive and dismissive? Hard to be sure. There was broad agreement in the group that the work itself was worthwhile, but this group wasn't at the right level of the stack. * Followup discussion was unproductive, felt like talking past each other. * Bron: could have set expectations better - presentation felt more like a sales pitch than a technical presentation. * IETF level - would help to have more orientation, like "shower before you get in the pool" - so people know what to expect. * Newcomer vs "Tourist" - expectation that there's lots of work to do and that someone coming to the IETF has to contribute as well as get what they want - it's a collaborative process, not a rubber stamp. * Pete: would help if we volunteer to guide people, up-front comms. - only helps if they're willing to learn about us though! * In a perfect world we may have been able to salvage something from the Montreal experience, but generally we're happy that we're a fairly welcoming group. We'll be thoughtful about how we handle new people going forward, and keep track of what's going on in the rest of the IETF. ACTION: nothing concrete, keep being thoughtful BIMI --- BIMI is organisational logo per message based on email authentication complience. Should we talk about BIMI? * more likely it belongs in DMARC than here. * would be good to discuss the work within the IETF and make sure we're handling security considerations wisely. * Governments are pushing DMARC, which is useful in their sphere of influence. BIMI helps push adoption by commercial interests. ACTION: no action taken, will keep talking Should we merge with other email related groups? --- * UTA is working on TLS1.3 recommendations and deprecating TLS1.1, so not really. * suggestion to try to put EXTRA and JMAP together on the schedule for future meetings, since much the same people come to both. ACTION: Bron to request co-location in Prague requests for EXTRA and JMAP.