[Standards] LAST CALL: XEP-0357 (Push Notifications)

Kevin Smith kevin.smith at isode.com
Wed Nov 21 14:00:57 UTC 2018

On 20 Oct 2018, at 12:51, Jonas Schäfer (XSF Editor) <jonas at wielicki.name> wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0357.
> Title: Push Notifications
> Abstract:
> This specification defines a way for an XMPP servers to deliver
> information for use in push notifications to mobile and other devices.
> URL: https://xmpp.org/extensions/xep-0357.html
> This Last Call begins today and shall end at the close of business on
> 2018-11-03.
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?


> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Partly. It is sufficient to know that there are data that might need fetching, but not sufficient to do any form of ‘quick sync’ rather than full catchup, which would be possible if the push notifications included a pointer to the data needing fetching - e.g. a message ID that needs fetching from MAM and then decrypted by an OMEMO client to update the local notification with the decrypted content.

The SHOULD on disabling on first iq error is likely to lead to issues in production if a service is ever restarted, leading to transient errors.

It’d also benefit from disabling notifications for a particular device’s service when that device is connected.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Yes, probably with adjustment.

> 4. Do you have any security concerns related to this specification?

Although it suggests limiting the provided information, it provides no guidance how this would work in practice (see (2)).

> 5. Is the specification accurate and clearly written?

Mostly. There’s at least one issue of MAY but SHOULD. It’s also not entirely clear from reading whether Disable means Delete (it does).


More information about the Standards mailing list