Minutes IETF103: jmap
minutes-103-jmap-00

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.