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

Andrzej Wojcik andrzej.wojcik at tigase.net
Tue Apr 7 07:55:22 UTC 2020



> Wiadomość napisana przez Florian Schmaus <flo at geekplace.eu> w dniu 07.04.2020, o godz. 09:45:
> 
> On 4/7/20 8:17 AM, Daniel Gultsch wrote:
>> Am Di., 31. März 2020 um 20:42 Uhr schrieb Jonas Schäfer <jonas at wielicki.name>:
>>> 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
>>> 2020-04-08.
>>> 
>>> Please consider the following questions during this Last Call and send
>>> your feedback to the standards at xmpp.org discussion list:
>>> […]
>>> 2. Does the specification solve the problem stated in the introduction
>>> and requirements?
>> 
>> No. At the very very least it requires an additional flag to tell
>> devices if this is a silent notification or a notification that
>> actually triggers something human readable.
> 
> Why is that? I would expect the push notification triggers the client on
> the device to look for further details of the event(s), which caused the
> push, on their service?

This is required for iOS, as high priority notifications cannot be muted or skipped on iOS.
Which means, that Push component is required to now if notification should be displayed or not.
It is not possible to filter them on the client side.

If it should, then high priority push is an option to use.
If not, then only normal priority push should be used.

>> But even that would be a hacky work around to what we really need; and
>> that is some form of abstract 'type' (text message, incoming call,
>> etc)
> 
> As above. I am trying to understand the motivation for this suggested
> change. Why does the push message have to carry additional information?
> I always assumed clients would simply fetch those after they received
> the push from their service. Are there cases where this is not sufficient?

Clients should not be forced to fetch. Fetching is not always possible, ie. on iOS
max timeout for fetch is up to 30s but it can be reduced to lower value by iOS
depending on usage, battery level, etc. Due to that it is not possible to be sure
that fetch will be possible.

Moreover, each fetch requires establishing connection, etc. It would be far better
to skip that and reduce energy usage.

At the Summit, I've suggested to send all required data within Push notification,
but for security reasons, encrypted by XMPP server initiating push notification. 
Here is a document which describes encryption process done by us at Tigase 
https://tigase.github.io/tigase-xeps/docs/push-notifications/encrypt/

> - Florian

Regards,
Andrzej Wójcik

XMPP: andrzej.wojcik at tigase.org
Email: andrzej.wojcik at tigase.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200407/427cdecf/attachment-0001.html>


More information about the Standards mailing list