Subject: [Jmap] Minutes for IETF103 meeting uploaded

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 07 Nov 2018 05:22:06 -0500

As always, please reply here with any corrections/clarifications! Thanks :) 
 
Bron. 
 
--- 
 
MINUTES - JMAP@IETF103 - Bangkok 7-Nov-2018 13:50 
 
Chairs: Barry Leiba and Bron Gondwana 
 
Thanks to dkg for jabber scribing and note taking. 
 
draft-ietf-jmap-core: 
* Q: has JMAP core been assessed for suitability outside email, since 
 it's designed as a general transport 
 - A: we're using it at FastMail for calendar, contacts, files, etc already 
 as well as some specialist extensions which aren't mail related. The 
 model works well, and reviewers have been favourable. 
* Q: what about queries across multiple accounts, should that be addressed 
 in core? 
 - A: let's talk about it later 
* Expecting minor nits changes based on reviews, but nothing major left, 
 expect to submit for publication at the end of WGLC on Nov 16. 
 
draft-ietf-jmap-mail: 
* No issues raised in the room 
* Expecting minor nits changes based on reviews, but nothing major left, 
 expect to submit for publication at the end of WGLC on Nov 16. 
 
multiple account queries: 
* Problem statement, want to aggregate sort across multiple "accountId"s, 
 for example - sort by search relevance and all accounts are on the same 
 server so use the same scoring system. 
* note: this has been requested by a few different client authors who 
 have user requests for a "combined INBOX" or similar. 
* observation: might be useful inside a single system, but a client which 
 is aggregating mailboxes from multiple external sources is going to have 
 to deal with this regardless, we can't make the whole world into a single 
 namespace! 
* suggestion: add a fetch property to an object like SearchSnippet which 
 can be used to combine the sorted lists on the client. 
* suggestion: have the server combine multiple users' email into a single 
 "accountId" (doesn't fix observation above, but might be enough for some 
 use cases) 
* suggestion: have server produce a combined "/query" result which 
 merges data from multiple accounts into some kind of list of tuples of 
 [accountId emailid] rather than just a list of emailIds. 
* observation: core and mail specs are already complex enough, this would 
 be much better as an extension rather than part of core/mail proper. 
 
ACTION: Benoit from Linagora to write up a proposal for an extension 
 based on their use-case. 

draft-ietf-jmap-mdn: 
* Concept has broad support 
* There are some nits in terms of JMAP-style 
* Needs to wait on core/mail standards in terms of process through 
 IETF, but may very well land at the same time (cluster!) 
 
ACTION: Neil to provide nits to the author for a new draft. 

draft-murchison-jmap-websocket: 
* Q: should multiple concurrent requests be allowed? 
 - A: yes! 
 - note: it may be necessary to add an identifier to requests and responses 
 to allow correlating reponses to their requests, since responses could 
 come back out of order. 
 - note: draft already shows JMAP over Websockets over http/2. 
 - note: QUIC can be considered separately/later. 
* Q: should we support push via the same channel? 
 - A: yes! We will need to tag it to distinguish it from responses 
* No objections to adoption within the room 
 
ACTION: Barry will mail list asking for objections to adoption before 
 Nov 16th. 
ACTION: Neil will give feedback on questions to Ken (author) for an 
 updated draft. 

draft-ietf-jmap-smime: 
* Posted by Alexey to the list, but looks like it wasn't uploaded (can't 
 find it in the datatracker) 
* suggestion: add an extra property giving the fingerprint or similar for 
 the key that matched 
* discussion: most UIs only care about "signed/verified" and "unknown", 
 anything not verified should be treated as "no comment"/"unknown". 
* note: some environments might require everything to be signed. 
* No objections to adoption within the room 
 
ACTION: Barry will mail list asking for objections to adoption before 
 Nov 16th. 

new extension: quota 
* Benoit from Linagora proposed a new extension for quota 
* discussion: complexity with different servers including other things 
 inside quota, not just mail. 
* note: most MUAs just care about showing a total, and a "you have used X%" 
 of your total. Exactness doesn't matter so much. 
* matches an IMAP data item, so clearly in scope 
* no objection from within the room 
 
ACTION: Benoit to post a proposal to the mailing list to form the 
 basis for a call for adoption 

Rechartering discussion: 
* Based on email thread from yesterday 
* Q: is the term "extension" overused 
 - e.g. both extending existing specs and adding new data types 
 - suggestion: say "data model" instead. 
 - suggestion: "capability" (but overloaded from IMAP meaning) 
* note: need to be clear about sequencing, this could open a floodgate 
 of work and don't want to overload group without clear priorities set. 
* Alexey as AD: don't recharter until existing docs have been through 
 IESG review, it would be a distraction. 
* warning: there's a danger of introducing circular dependencies if we 
 work on too many related documents at once. 
* suggestion: limit this recharter to just calendars and contacts, and 
 recharter again once those are done. 
 
ACTION: Bron to keep refining text with an eye to rechartering in January. 

Miletones: 
* Bron has updated existing milestones, except IMAP/JMAP compatibility 
 document which Alexey was going to work on. 
* suggestion: leave doc in the milestones, but change the target date to 
 December 2020 to put it behind other work. 
* this document is less urgent now that the EXTRA working group has added 
 many things to IMAP which will help. 
* Alexey is happy if someone else wants to take up work on this document. 
 
ACTION: Bron to update milestone date 

There being no other business, the meeting was concluded after roughly 1 hour. 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]