Sorry for my last message! I replied to the wrong thread... So here is the correct reply :)
As I said already in another thread: https://mail.jabber.org/pipermail/standards/2018-October/035387.html : This XEP needs at least a note discouraging the use of the fields "message- sender" and "message-body" because of privacy implications. In the wild the field "message-body" is left empty for low priority pushes (in short: pushes not related to message stanzas containing a body) and set to something like "New Message!" for high priority pushes. This is at least needed for iOS apps not having VoIP permissions. The field "message-count" is ambiguous and should be removed completely or defined what is counted by it. The prosody implementation hardcodes its value to "1". The field "pending-subscription-count" is not used by prosody at all. I don't know if other implementations use it. The business rules proposed by Daniel should be incorporated into the XEP as well: https://mail.jabber.org/pipermail/standards/2016-February/030925.html Prosody's implementation rationale for these are explained here: https:// hg.prosody.im/prosody-modules/file/tip/mod_cloud_notify/business_rules.markdown AND https://mail.jabber.org/pipermail/standards/2018-October/035396.html : > Appserver might take notice that app didn't wake up after three > content-update notification and send an alert notification on fourth > attempt. We don't do that, however. Well, that wouldn't make for good UX at all. Push notifications are sent for non-body messages, too. Having an alert notification without some visible change when you open the app (because only "silent" xmpp stanzas triggered push) is bad. And imho chatting is about real-time communication. Missing (maybe important) messages for several minutes or maybe for hours just because fewer than 3 pushes were sent out is bad, too (some account with only a few contacts, something often seen with xmpp newcomers). I agree that the only viable solution is to implement some VoIP capability short of apple changing their policy, BUT: Having a priority for messages helps where that is not feasible (or something that will be implemented later after other XMPP functions have been implemented). And there could come other push services for which this priority thing will be needed, too. The thing is: Having the capability for priorizing messages when needed in the XEP will reflect what ChatSecure and possibly others need and are already doing. Not standardizing this despite of demand in this will ensure every app needing this will do some homegrown not interoperable implementation/patch. Chatseucre demanded its users to patch prosody to support a priority field. AND: not standardizing this will just not reflect reality. Prosody AND ejabberd both allow the last-message field to be used for priority signaling. Standardizing a new field for this and removing the new-message field altogether would be better, privacy wise and standards wise. Cheers, Thilo Am Samstag, 20. Oktober 2018, 11:51:54 CET schrieb Jonas Schäfer: > 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@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? > > 3. Do you plan to implement this specification in your code? If not, > why not? > > 4. Do you have any security concerns related to this specification? > > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
