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?

> 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?

- Florian

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to