On 18.03.2017 11:16, Dave Cridland 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.
My point was to address the original intention to update XEP-0198 and
other state-related XEPs - with proposal to update state-related XEPs
with simple wording that "state is always preserved, but what is that
preserved state depends on state change being acked by SM or other
relevant mechanism, otherwise state on resumption is undefined".
Now, we know that stanzas are always acked - so everything IQ-driven is
preserved. CSI - is nonza, and currently nonzas are not tracked by SM.
So until SM is advanced to support nonzas as well - nonza driven state
on resumption is undefined. If client has possibility to identify nonza
acks by in-order-processing rule - it may consider nonzas as being acked
hence the state on resumption to be known.
The idea is to avoid making additional fuss to enforce state to be
either way on client or server side during resumption. Just keep it as
is. And if you're not sure what is that 'as-is' - just set it explicitly.
Regards,
Ruslan
P.S> The PR comments touched compression topic. Compression is transport
feature, it's negotiated before resumption. What is being resumed is XML
document content/body, not framing/headers.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
