On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote: > On 18.03.2017 09:43, Dave Cridland wrote: >> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@ruff.mobi >> <mailto:m...@ruff.mobi>> wrote: >> On 11.02.2017 21:43, Florian Schmaus wrote: >> It should be explicitly stated that the CSI state is *not* >> (because it >> can not) restored after a stream resumption. I've created a PR to >> address this: https://github.com/xsf/xeps/pull/402 >> <https://github.com/xsf/xeps/pull/402> >> >> Why *not* btw? Device may detect the connection is dropped (by >> server) while still being inactive. The fact it waked from deep >> sleep does not indicate it's active. >> I convinced it should be quite opposite. The only reason to not >> being restored is because (at the moment) it is nonza and nonzas are >> not smacked. >> >> If handheld emits csi/csa events based on user interaction and not >> power-management events it may be a bit complicated *not*-restoring >> state and then pushing it back to inactive. >> The sole fact of resumption means all undelivered (eg. queued) >> stanzas are to be delivered - as on any other message delivery. Then >> it may continue sleeping as it was before. >> Unless it's really active now. >> >> Perhaps it should be kind of conditional statement - unless CSI is >> acked - the state *must not* be assumed to be either restored or >> reset - hence it's responsibility of the client to set it back to >> the desired state. >> >> >> You can't rely on the state being acknowledged, because that would >> require both sides to know that the client has seen the ack. > > Does the server really need to know if the client received the ack? > Right now I think along the lines of: > - the server simply always restores the CSI state > - the client keeps track if the last CSI state change was acknowledged > - if it was not acknowledged, the client resets the CSI state to its > desired state > > What am I missing here? >
Well, yes, the client would have to always set the state unless it'd seen the ack; that's the workaround. But in this case you might as well simplify things and always set it anyway. >> Luckily all this doesn't matter. We can set the CSI state during >> resumption without additional round trips using SASL2 and IBR2 extensions. > > I see how XEP-0388/SASL2 could achieve this, but how does XEP-0389/IBR2 > fit into this? > Only in as much as we're talking about resumption. > - Florian > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
