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.
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: standards-unsubscr...@xmpp.org
_______________________________________________
