[Standards] XEP-0357: Push Notifications is missing business rules section

Daniel Gultsch daniel at gultsch.de
Tue Feb 16 12:32:16 UTC 2016


I finally found the time to implement client side support for XEP-0357:
Push Notifications (and also wrote my own app server in the process.)

For testing purposes it is working quite well with both the ejabberd module
and the prosody module (Many thanks to the respective developers for
implementing them.)

However the XEP is missing some important business rules on *when* to send
push notifications. It only describes the how. I think this should be
clarified for the sake of consistency across multiple clients and multiple

After some consideration and discussions with server developers I came to
believe that the following rules are desirable:

1) A server - over time - collects the various delivery targets which are a
combination of jid and node attribute + x contained in the enable request.
2) A client resends those on every connect (because it can not know whether
the server already knows about this particular delivery target.
3) As a consequence of (2) the server knows the delivery target for a
particular session
4) There are three different 'push scenarios' (Situations in which the
server should initiate a push)
a) In a XEP-0198 stream management session with a closed TCP connection the
server should notify the corresponding delivery target on every new stanza
that would have been delivery if the TCP stream was alive (meaning all
stanzas but honouring CSI if enabled.)
b) If a message is being archived into MAM (honouring the MAM archiving
rules) *every* delivery targets should be notified unless that delivery
target was already notified by rule (a)
c) copies rule (b) for offline messages meaning all delivery targets should
be notified when a new offline message arrives.

(c) and (b) can be combined into one push scenario depending on the server
implementation (when MAM and offline are fed by the same data source)

for (a) it is no required to keep the session open for much longer than
regular. (ejabberd currently does this so i'm saying this here)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160216/5d68ce78/attachment.html>

More information about the Standards mailing list