Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 18.03.2017 11:16, Dave Cridland wrote:

On 18 March 2017 at 09:53, Florian Schmaus  wrote:

On 18.03.2017 09:43, Dave Cridland wrote:

On 17 Mar 2017 21:52, "Ruslan N. Marchenko" > 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.

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

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Dave Cridland]

On 18 March 2017 at 10:16, Dave Cridland  wrote:
> On 18 March 2017 at 09:53, Florian Schmaus  wrote:
>> On 18.03.2017 09:43, Dave Cridland wrote:
>>> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" >> > 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.
>>
>> 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: standards-unsubscr...@xmpp.org
>> ___
>>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Dave Cridland]

On 18 March 2017 at 09:53, Florian Schmaus  wrote:
> On 18.03.2017 09:43, Dave Cridland wrote:
>> On 17 Mar 2017 21:52, "Ruslan N. Marchenko" > > 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.
>
> 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.

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

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Dave Cridland]

On 17 Mar 2017 21:52, "Ruslan N. Marchenko"  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: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___