[Standards] XEP-0357: Push Notifications is missing business rules section
daniel at gultsch.de
Fri Jun 17 12:55:23 UTC 2016
now Push is getting some traction. Multiple (even larger) server operators
have enabled the Prosody module. Conversations has client side support for
it. ChatSecure iOS with Push support is going to be released soon. The
ejabberd module is in planing stages as well. It is very important that
client and server devs are on the same page and have a common ground to
work with. IMHO this Push XEP is clearly missing some business rules. I
started writing up some rules a few month ago and I'm still convinced that
those are the 'correct' conditions. At least for an IM context. I would
really love to formalize them in the XEP since feedback has generally be
2016-02-16 13:32 GMT+01:00 Daniel Gultsch <daniel at gultsch.de>:
> 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)
I have a small modification/footnote to (a): The server should keep the
smacks session open for $normal-timeout after sending the first push. As
apposed to an extremely long timeout like 12h our 'infinite' this puts
much less stress on the server. But also gives an idle client a fair chance
to still resume a session.
I would also like to incude these client side rules: (For IM)
If you have the ability to resume a smacks session on your platform.
(Either because the OS doesn't kill or because your library allows you to
serialize to disk) you should just close the socket when going to
background instead of closing the stream. This way you will always be in
'push scenario' (a). And you avoid having to create a whole new session on
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards