[Extra] Minutes of today's session uploaded

["Bron Gondwana" <[e-mail]>]

And attached inline. As always, any corrections or clarifications, please post them here! 
 Thanks,
 
Bron. 
 
--- 
 
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. 
 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [e-mail]