Jmap Status PagesJSON Mail Access Protocol (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2017-Mar-16 —Chairs:
IETF-103 jmap minutes
Session 2018-11-07 1350-1520: Boromphimarn 3 - Audio stream - jmap chatroom
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.