Subject: [Jmap] Push specification

From: Neil Jenkins <[email-masked]>
Date: Mon, 18 Sep 2017 14:37:17 +1000

I've got a pull request[1] I'd like to merge this week, addressing the
concerns that were raised about the push specification at the previous
IETF conference. I think this is just about ready to merge (thanks to
Martin Thomson for several rounds of expert review so far), so this is a
last call if you want to review this and provide any further feedback on
this change.
The changes are mostly editorial, to make the spec clearer. More
substantive changes are:
 * Changes to HTTP headers sent with web callback to make it conform
   with the use of a push endpoint by an Application Server as defined
   in RFC8030.
 * Support for encryption of the push data (as per
   https://tools.ietf.org/html/draft-ietf-webpush-encryption-09, but
   will be an RFC before JMAP so we'll update the reference when
   this is done).
 * Change of method name to set/get URL to match RFC8030 terminology.
 * Ability to use event-source in long-polling mode by setting a query
   parameter, and to set a custom ping time (in another query
   parameter) to help clients detect if buffering proxies mean long-
   poll mode is required.
The only outstanding comment I believe I currently have from Martin is
to define when encryption may be omitted. If the push server is
controlled by the same entity as the JMAP server then there is clearly
no benefit in encrypting the payload (presuming the connection between
the client and the push server is itself encrypted anyway). In the case
of a 3rd-party push server, is encryption a SHOULD or a MUST? Opinions?
Regards,
Neil.

Links:

  1. https://github.com/jmapio/jmap/pull/100