On 18 March 2017 at 10:16, Dave Cridland <[email protected]> wrote: > On 18 March 2017 at 09:53, Florian Schmaus <[email protected]> wrote: >> On 18.03.2017 09:43, Dave Cridland wrote: >>> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <[email protected] >>> <mailto:[email protected]>> 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.
As you point out, I mean I*S*R. Suffering from acronym overload... > >> - Florian >> >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
