[Standards] XEP-352 CSI - server behaviour when client's inactive but sends stanzas

Michal Piotrowski michal.piotrowski at erlang-solutions.com
Thu Mar 31 16:37:24 UTC 2016

Thanks for your response. I understand that the extension is about not
sending data from the server to the inactive client.
However it is still possible that a malicious user trying to abuse the csi
behaviour (a bot rather than mobile client). Maybe I'm too careful here and
the server should behave as you described.

Best regards
Michal Piotrowski
michal.piotrowski at erlang-solutions.com

On 31 March 2016 at 16:01, Florian Schmaus <flo at geekplace.eu> wrote:

> On 31.03.2016 15:26, Michal Piotrowski wrote:
> > Hi,
> >
> > The XEP-352 http://xmpp.org/extensions/xep-0352.html doesn't say much
> > about servers behaviour. I'm wondering what should happen when client
> > goes into inactive state but sends messages after that.
> >
> > Should the server respond with an error and discard the stanza? Or maybe
> > should the server buffer these stanzas and process them later when
> > client is back active?
> Huh? Are you talking about the case where a client sends <inactive/> and
> then some stanza? Why shouldn't the server just handle the stanza
> normally, i.e. as if CSI was not in use?
> CSI is mostly about elements being send from the server to the client,
> not the other way around. Only the sending entity is able to optimize
> the outgoing traffic: The (mobile) client has to prevent unnecessary
> outgoing elements to the server and the server has to prevent
> unnecessary elements to the mobile client to prevent battery drain.
> A server may want to use the indication that the client is up (and that
> its radio is powered up) to e.g. send some queued stanzas to the client.
> But that is up to the server implementation (and could possible cause
> more harm than good, although I doubt it).
> - Florian
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160331/771bfd3e/attachment.html>

More information about the Standards mailing list