On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <[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 > > 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. And then we run into Two Generals. Carbons is controlled by stanzas - probably wrongly - but it means the state is known. Luckily all this doesn't matter. We can set the CSI state during resumption without additional round trips using SASL2 and IBR2 extensions. So xep-0198 in current state is right to note the state may not be considered preserved for CSI. Although carbons... set by acked iq, why won't it be preserved? What is the rationale? Why one IQ (roster, blocking/privacy/visibility) is preserved and another (carbons) is not? Regards, Ruslan _______________________________________________ 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] _______________________________________________
