On 31 March 2016 at 17:37, Michal Piotrowski < [email protected]> 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 > [email protected] > > On 31 March 2016 at 16:01, Florian Schmaus <[email protected]> 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: [email protected] >> _______________________________________________ >> >> > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
