Minutes IETF102: jmap
minutes-102-jmap-00

JMAP IETF102 Minutes - Montreal / 16-Jul-2018 13:30-14:30

Core
----

* Error Registry
 - Registry is infrastructure - better to get it in place up front!
 - Chris Newman will write text

* Push Filtering
 - Keep default behaviour as "push everything for data type"
 - Create an extension for "filtered push" as a separate option

* Explicit totals
 - We're going to change to "require client to ask for totals"
 - If the client doesn't ask, server MUST NOT send totals, because
   clients often just test against an implementation.

* Last Call
 - no objections in the room to going to last call after applying
   this current set of changes

Mail
----

* Group Names
 - lots of discussion, will finalise on the list

* Splitting out extensions
 - will keep vacation in the mail spec document
   * but with a separate capability, so there's an example
     in the spec of how to do extensions to it.
 - attachment searching is covered by updated text in the spec
   * "search in non-text bodyparts"
   * would be useful to know which MIME bodyparts matched

* Last Call
 - no objections in the room to going to last call after applying
   this current set of changes

Extensions
----------

* Re-charter
 - more likely to succeed if we have an initial set of extensions that
   we plan to work on rather than fully open-ended.
 - will start with what we have now

* websockets
 - FastMail and Isode are interested
 - Ken to keep working on it
 - wsUrl to be moved under capabilities because there's already a
   registry there, so no namespace clash issues

* sieve
 - Definite interest
 - Very few clients allow full sieve editing, instead having a more
   simplistic rule builder.
 - Do we want to offer an intermediate format?  (like how JMAP hides
   the full MIME complexity)
 - to be discussed on the list

* MDN
 - Definite interest
 - Will go to the list for an author

* single HTML file
 - No demand for it yet, so shelved
 - Question: is there a standard "web archive" format yet?  Should consider
   that as a way to bundle images, etc.

* search in attachments
 - see above: non-text body parts
 - it's impossible to get all possible searchable text to match user
   expectation (e.g. OCR of text-like images), so it will always depend
   on what servers can do
 - put text in the spec detailing the user experience behaviour, but don't
   constrain server

Other Business
--------------

Discussion went back to nulls and groups in the asAddresses representation,
and nothing was resolved.