* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Jmap Status Pages

JSON 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

minutes-103-jmap-00 minutes



          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.
          
          



Generated from PyHt script /wg/jmap/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -