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

Dave Cridland dave at cridland.net
Thu Mar 31 21:02:39 UTC 2016


On 31 March 2016 at 17:37, Michal Piotrowski <
michal.piotrowski at erlang-solutions.com> wrote:

> 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.
>
>
I don't think there ought to be any abuse possible here. A CSI Inactive
client can send stanzas if it wants to. A server could respond immediately,
or might respond later. CSI leaves server behaviour very loose, by intent.

If you think there's a possible exploit here, feel free to protect your
server from it, but also post to the list.


>
> 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
>> _______________________________________________
>>
>>
>
> _______________________________________________
> 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/8a14322d/attachment.html>


More information about the Standards mailing list