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

[Kim Alvefur]

On Tue, Aug 04, 2020 at 04:05:22PM -, XEP Editor Pipeline wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
> 
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-08-18.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Plugins for Prosody has been around since 2014¹ and is included with the
latest release.

There exists several modules providing optimization strategies.

> 4. Do you have any security concerns related to this specification?

No.

I can imagine that delaying stanzas into batches can make it harder to
exploit timing side-channels, as an unintentional bonus.

> 5. Is the specification accurate and clearly written?

The specification is intentionally brief on specific server behavior.
I'm okay with this.

A future Informational XEP on what works well and what doesn't would be
great, but I'm not sure we have enough experience at this point. Until
then, experimenting and gathering experience seems like the thing to do.

¹ https://modules.prosody.im/mod_csi.html

-- 
Regards,
Kim "Zash" Alvefur
Prosody developer


signature.asc
Description: PGP signature
___
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)

[Georg Lukas]

* XEP Editor Pipeline  [2020-08-04 18:07]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Partially. The XEP omits explicit requirements on how a server should
optimize traffic, so an implementation that just consumes the CSI
commands would be perfectly conforming.

The lack of guidance has led to the creation of some tribal knowledge
of what can and what shouldn't be optimized. For one widely-used server
implementation there are multiple extension modules that implement
slightly different optimization techniques, resulting in inconsistencies
of behavior. Also, somebody who wants to implement this specification is
in for a rough ride, learning the hard way that e.g. you can suppress
presence updates to an inactive client, but you shouldn't suppress the
join presence for the client joining a MUC, or the join would timeout.

I see significant value in formalizing this tribal knowledge, even with
non-mandatory language, ideally inside of this XEP (or in an addenum
XEP, for lack of a better vehicle).

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Implemented it in yaxim back in 2014 (using legacy google:queue
signaling), and switched to CSI in 2018.

> 4. Do you have any security concerns related to this specification?

No.

> 5. Is the specification accurate and clearly written?

Yes.



Georg


signature.asc
Description: PGP signature
___
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)

[Holger Weiß]

* XEP Editor Pipeline  [2020-08-04 16:05]:
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-08-18.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes, at least as long as there's clients maintaining a persistent
connection and interested in having the server perform traffic
optimizations.  But I can also imagine other use cases for making the
server aware of the client state.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I've implemented it for ejabberd in 2014.

> 4. Do you have any security concerns related to this specification?

No.

> 5. Is the specification accurate and clearly written?

Yes.

Holger
___
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)

[Ruslan N. Marchenko]

Am Dienstag, den 04.08.2020, 16:05 + schrieb XEP Editor Pipeline:
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
> 
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-08-18.
> 
> Please consider the following questions during this Last Call and
> send
> your feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
> 
Yes
> 2. Does the specification solve the problem stated in the
> introduction
> and requirements?
> 
Yes
> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 
Yes, implemented in client and server stacks
> 4. Do you have any security concerns related to this specification?
> 
No
> 5. Is the specification accurate and clearly written?
> 
Yes
> Your feedback is appreciated!
> ___
> 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)

[Daniel Gultsch]

On Dec 7, 2017 18:37, "Jonas Wielicki"  wrote:

This message constitutes notice of a Last Call for comments on
XEP-0352.

Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.

URL: https://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on
2017-12-21.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


Yes


2. Does the specification solve the problem stated in the introduction
and requirements?


Yes


3. Do you plan to implement this specification in your code? If not,
why not?


Yes. I did. Like three years ago or so.


4. Do you have any security concerns related to this specification?


No


5. Is the specification accurate and clearly written?


Yes


Your feedback is appreciated!
___
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)

[Ruslan N. Marchenko]

On 07.12.2017 18:35, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0352.

Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.

URL: https://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on
2017-12-21.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


Yes.


2. Does the specification solve the problem stated in the introduction
and requirements?

Yes.


3. Do you plan to implement this specification in your code? If not,
why not?

Yes.


4. Do you have any security concerns related to this specification?

No.


5. Is the specification accurate and clearly written?

It is intentionally leaves lot of space for implementers, but we can 
live with it for the time being.
Presence and bodiless stanzas are called out and they represent majority 
of the messages which could be safely dropped/delayed (yes, there's also 
omemo).


___
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)

[Kevin Smith]

On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor)  
wrote:
> 
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
> 
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2017-12-21.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

It was, it’s less clear that it still is. Once upon a time, clients on mobile 
would continue to run in the background in a useful way, at least on Android 
(it’s never really been the case for iOS unless you abused APIs), but these 
days even Android is moving away from this towards other mechanisms that might 
be more appropriate for us (e.g. Push).

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

The requirement is basically to implement CSI, so yes :)

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Not currently - I don’t think it solves the issues for mobile that it once did, 
at least in the mid-future, so I’ll be inclined to concentrate on Push and 
other needed parts (like fast reconnects).

> 4. Do you have any security concerns related to this specification?

I have a feeling that the current prose that semi-recommends bypassing 
6120/6121 rules and silently dropping stanzas from the middle of a stream might 
introduce security issues in subtle ways, although I haven’t yet thought of any.

> 5. Is the specification accurate and clearly written?

I think the suggested-but-not-normative server behaviours either need more 
fleshing out, or probably shouldn’t be included.
"   • Suppress presence updates until the client becomes active again. On 
becoming active, push the latest presence from each contact.”
For example can go wrong in interesting ways, depending how you interpret it, 
and break PEP, MUC, or presence subscribing.

"Regardless of what optimisations a server implements, it SHOULD provide a way 
for administrators to configure them”

I think this text is trying to avoid a server doing RFC-breaking things without 
allowing an admin to opt-out. If that’s the case, I suggest that it would 
instead be better to say that a server MUST NOT introduce any RFC-breaking 
optimisations by default. If that’s not the case, I think mandating what’s 
configurable is probably not appropriate.

"If the server supports CSI, it advertises it in the stream features after the 
client has authenticated:”

I feel like we’ve probably discussed this is the distant past, but it seems 
(uniquely?) inconsistent to advertise stream features that are only used after 
the stream is set up and the user could disco instead.

"For example: A client sends a CSI active nonza”

I don’t think using the ‘nonza’ term (and inconsistently at that) is aiding the 
reading of the XEP here. We can say “element” (as we do elsewhere in the spec) 
and be at least as clear as nonza, without inventing new, confusing 
nomenclature.

"That is, stream resumption does not affect the current CSI state, which always 
defaults to 'active' for new and resumed streams”

I think this intends to say the opposite of what it says, doesn’t it? Stream 
resumption *does* affect the current CSI state, which it resets to ‘active’.

"To protect the privacy of users, servers MUST NOT reveal the clients 
active/inactive state to other entities on the network.”

I’d have thought exposing this to admins of the user’s server is probably fine 
(plus obvious grammar slip), although maybe that doesn’t need this sentence 
changed.

/K
___
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)

[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
___

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

[Florian Schmaus]

On 17.03.2017 22:51, 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
>
> 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.

Yep, that would be the other option.

See https://github.com/xsf/xeps/pull/427#issuecomment-287486913

- Florian



signature.asc
Description: OpenPGP digital signature
___
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)

[Ruslan N. Marchenko]

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
___

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

[Sam Whited]

On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor  wrote:
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).

Since there is still open feedback and open changes on this XEP, I
have extended the Last Call again.

The LC will now end on 2017-03-28.

—Sam
___
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)

[Jakob Schröter]

On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor  
 wrote:
1. Is this specification needed to fill gaps in the XMPP protocol  
stack or to clarify an existing protocol?


Yes.

2. Does the specification solve the problem stated in the  
introduction and requirements?


Yes.

3. Do you plan to implement this specification in your code? If  
not, why not?


Already done.


4. Do you have any security concerns related to this specification?


No.


5. Is the specification accurate and clearly written?


Yes.


Jakob


___
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)

[Michal Piotrowski]

On 9 February 2017 at 00:07, XMPP Extensions Editor  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0352
> (Client State Indication).
>
> Abstract: This document defines a way for the client to indicate its
> active/inactive state.
>
> URL: http://xmpp.org/extensions/xep-0352.html
>
> This Last Call begins today and shall end at the close of business on
> 2017-02-22.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
> to clarify an existing protocol?
>

Yes


> 2. Does the specification solve the problem stated in the introduction and
> requirements?
>

Yes


> 3. Do you plan to implement this specification in your code? If not, why
> not?
>

Already implemented


> 4. Do you have any security concerns related to this specification?
>

No


> 5. Is the specification accurate and clearly written?
>

Yes


>
> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>



Best regards
Michal Piotrowski
michal.piotrow...@erlang-solutions.com
___
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)

[Daniel Gultsch]

2017-02-09 0:07 GMT+01:00 XMPP Extensions Editor :
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?
Yes
> 2. Does the specification solve the problem stated in the introduction and 
> requirements?
Yes
> 3. Do you plan to implement this specification in your code? If not, why not?
Yes. I already did.
> 4. Do you have any security concerns related to this specification?
No
> 5. Is the specification accurate and clearly written?
Yes
___
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)

[Florian Schmaus]

On 09.02.2017 00:07, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).
> 
> Abstract: This document defines a way for the client to indicate its 
> active/inactive state.
> 
> URL: http://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2017-02-22.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

Yes.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not, why not?

Already implemented.

> 4. Do you have any security concerns related to this specification?

No.

> 5. Is the specification accurate and clearly written?

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

I want to express that CSI is a prime example for a powerful, well
designed, yet easy to implement XEP.

- Florian




signature.asc
Description: OpenPGP digital signature
___
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)

[Ruslan N. Marchenko]

On 09.02.2017 00:07, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0352 (Client 
State Indication).

Abstract: This document defines a way for the client to indicate its 
active/inactive state.

URL: http://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on 
2017-02-22.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?

Yes, certainly, see google:queue to address this same gap

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes

3. Do you plan to implement this specification in your code? If not, why not?

Yes

4. Do you have any security concerns related to this specification?

No

5. Is the specification accurate and clearly written?

Excuse me my ignorance if it was clarified before but...
I still don't understand rationale behind choosing nonza. Server may 
wish to route/propagate the stanza to connected services/components to 
shut up and don't bother the user. After all it's client state 
indication, not stream state.
The only benefit of using nonza (apart from the size) is that after 
sending  client may just go sleeping without waiting for 
iq/response to digest tcp queue.
But with in-order processing requirements - server will process nonza 
after all queued stanzas, which means it actually makes sense waiting 
for iq/response as a confirmation of the active state closure on the 
given stream.
I.e. to be sure whatever comes in after that is really important, not 
leftovers of the previous active state, hence worth waking up.
Aside from that it lacks explicit instructions to add  tag to 
any deferred/queued/held stanzas.
And then "In-order processing" section misses this case for any such 
delayed stanzas should be delivered(flushed) in-order whenever stanza 
which could not be delayed needs to be delivered. This is maybe obvious 
from overall protocol specification but if someone volunteers to 
implement just a feature - there could be concerns/misunderstandings.

Your feedback is appreciated!
___
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)

[Kurt Zeilenga]

I support adding of the proposed text.  — Kurt

> On Sep 22, 2015, at 1:53 PM, Peter Saint-Andre -   
> wrote:
> 
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>> This message constitutes notice of a Last Call for comments on XEP-0352 
>>> (Client State Indication).
>>> 
>>> Abstract: This document defines a way for the client to indicate its 
>>> active/inactive state.
>>> 
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>> 
>>> This Last Call begins today and shall end at the close of business on 
>>> 2015-09-07.
>>> 
>>> Please consider the following questions during this Last Call and send your 
>>> feedback to the standards@xmpp.org discussion list:
>>> 
>>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or 
>>> to clarify an existing protocol?
>> Yes.
>> 
>>> 2. Does the specification solve the problem stated in the introduction and 
>>> requirements?
>> Yes.
>> 
>>> 3. Do you plan to implement this specification in your code? If not, why 
>>> not?
>> Yes.
>> 
>>> 4. Do you have any security concerns related to this specification?
>> No.
>> 
>>> 5. Is the specification accurate and clearly written?
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
> 
> I'd love to see some list discussion about that suggestion. :-)
> 
> The proposed text is:
> 
> ###
> 
> XMPP requires stanzas to be processed in order as per  10.1. 
> Especially "If the server's processing of a particular request could have an 
> effect on its processing of subsequent data it might receive over that input 
> stream..., it MUST suspend processing of subsequent data until it has 
> processed the request.". As a result, all actions triggered by a CSI nonza 
> sent to the server must happen before processing further requests from the 
> same client to the server.
> 
> For example: A client sends a CSI active nonza, followed by an XMPP Ping 
> request to the server. The server first changes the CSI state to active and 
> flushes all eventually queued stanzsa. After the state has been restored to 
> 'active' and all resulting stanzas have been put on the wire, the server 
> sends the pong.
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
>  type='result'/>
> 
> 
> 
> ###
> 
> Thoughts?
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/

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

[Kevin Smith]

On 22 Sep 2015, at 21:53, Peter Saint-Andre -   wrote:
> 
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>> This message constitutes notice of a Last Call for comments on XEP-0352 
>>> (Client State Indication).
>>> 
>>> Abstract: This document defines a way for the client to indicate its 
>>> active/inactive state.
>>> 
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>> 
>>> This Last Call begins today and shall end at the close of business on 
>>> 2015-09-07.
>>> 
>>> Please consider the following questions during this Last Call and send your 
>>> feedback to the standards@xmpp.org discussion list:
>>> 
>>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or 
>>> to clarify an existing protocol?
>> Yes.
>> 
>>> 2. Does the specification solve the problem stated in the introduction and 
>>> requirements?
>> Yes.
>> 
>>> 3. Do you plan to implement this specification in your code? If not, why 
>>> not?
>> Yes.
>> 
>>> 4. Do you have any security concerns related to this specification?
>> No.
>> 
>>> 5. Is the specification accurate and clearly written?
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
> 
> I'd love to see some list discussion about that suggestion. :-)
> 
> The proposed text is:
> 
> ###
> 
> XMPP requires stanzas to be processed in order as per  10.1. 
> Especially "If the server's processing of a particular request could have an 
> effect on its processing of subsequent data it might receive over that input 
> stream..., it MUST suspend processing of subsequent data until it has 
> processed the request.". As a result, all actions triggered by a CSI nonza 
> sent to the server must happen before processing further requests from the 
> same client to the server.
> 
> For example: A client sends a CSI active nonza, followed by an XMPP Ping 
> request to the server. The server first changes the CSI state to active and 
> flushes all eventually queued stanzsa. After the state has been restored to 
> 'active' and all resulting stanzas have been put on the wire, the server 
> sends the pong.
> 
> 
> 
> 
> /balcony' id='ping1' type='get'>
>  
> 
> 
> 
> 
> /baclony' 
> from='capulet.lit' id='ping1' type='result'/>
> 
> 
> 
> ###
> 
> Thoughts?

That text seems consistent with in-order processing requirements, so it doesn’t 
hurt to spell it out.

/K

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

[Matthew Wild]

On 22 September 2015 at 21:53, Peter Saint-Andre - 
 wrote:
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>>
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>>
>>> This message constitutes notice of a Last Call for comments on XEP-0352
>>> (Client State Indication).
>>>
>>> Abstract: This document defines a way for the client to indicate its
>>> active/inactive state.
>>>
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>>
>>> This Last Call begins today and shall end at the close of business on
>>> 2015-09-07.
>>>
>>> Please consider the following questions during this Last Call and send
>>> your feedback to the standards@xmpp.org discussion list:
>>>
>>> 1. Is this specification needed to fill gaps in the XMPP protocol stack
>>> or to clarify an existing protocol?
>>
>> Yes.
>>
>>> 2. Does the specification solve the problem stated in the introduction
>>> and requirements?
>>
>> Yes.
>>
>>> 3. Do you plan to implement this specification in your code? If not, why
>>> not?
>>
>> Yes.
>>
>>> 4. Do you have any security concerns related to this specification?
>>
>> No.
>>
>>> 5. Is the specification accurate and clearly written?
>>
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
>
>
> I'd love to see some list discussion about that suggestion. :-)
>
> The proposed text is:
>
> ###
>
> XMPP requires stanzas to be processed in order as per  10.1.
> Especially "If the server's processing of a particular request could have an
> effect on its processing of subsequent data it might receive over that input
> stream..., it MUST suspend processing of subsequent data until it has
> processed the request.". As a result, all actions triggered by a CSI nonza
> sent to the server must happen before processing further requests from the
> same client to the server.
>
> For example: A client sends a CSI active nonza, followed by an XMPP Ping
> request to the server. The server first changes the CSI state to active and
> flushes all eventually queued stanzsa. After the state has been restored to
> 'active' and all resulting stanzas have been put on the wire, the server
> sends the pong.
>
> 
>
> 
>  type='get'>
>   
> 
>
> 
>
>  type='result'/>
>
> 
>
> ###
>
> Thoughts?

+1 to Florian's text. It clarifies what I believe to be the correct
behaviour, and it hopefully satisfies Florian's use-case for CSI :)

Regards,
Matthew

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

[Florian Schmaus]

On 26.08.2015 17:59, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).
> 
> Abstract: This document defines a way for the client to indicate its 
> active/inactive state.
> 
> URL: http://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2015-09-07.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?
Yes.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?
Yes.

> 3. Do you plan to implement this specification in your code? If not, why not?
Yes.

> 4. Do you have any security concerns related to this specification?
No.

> 5. Is the specification accurate and clearly written?
I'd like to see https://github.com/xsf/xeps/pull/44 merged.

- Florian



signature.asc
Description: OpenPGP digital signature

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

[Kurt Zeilenga]

> On Aug 26, 2015, at 8:59 AM, XMPP Extensions Editor  wrote:
> 
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).
> 
> Abstract: This document defines a way for the client to indicate its 
> active/inactive state.
> 
> URL: http://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2015-09-07.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

seems useful.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

seems so.

> 3. Do you plan to implement this specification in your code? If not, why not?

as part of this last call, I implemented this in M-Link, so yes.

> 4. Do you have any security concerns related to this specification?

not beyond what is stated.

> 5. Is the specification accurate and clearly written?

yes.

> 
> Your feedback is appreciated!

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

[Peter Saint-Andre -]

On 9/22/15 11:48 AM, Florian Schmaus wrote:

On 26.08.2015 17:59, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0352 (Client 
State Indication).

Abstract: This document defines a way for the client to indicate its 
active/inactive state.

URL: http://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on 
2015-09-07.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?

Yes.


2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes.


3. Do you plan to implement this specification in your code? If not, why not?

Yes.


4. Do you have any security concerns related to this specification?

No.


5. Is the specification accurate and clearly written?

I'd like to see https://github.com/xsf/xeps/pull/44 merged.


I'd love to see some list discussion about that suggestion. :-)

The proposed text is:

###

XMPP requires stanzas to be processed in order as per  10.1. 
Especially "If the server's processing of a particular request could 
have an effect on its processing of subsequent data it might receive 
over that input stream..., it MUST suspend processing of subsequent data 
until it has processed the request.". As a result, all actions triggered 
by a CSI nonza sent to the server must happen before processing further 
requests from the same client to the server.


For example: A client sends a CSI active nonza, followed by an XMPP Ping 
request to the server. The server first changes the CSI state to active 
and flushes all eventually queued stanzsa. After the state has been 
restored to 'active' and all resulting stanzas have been put on the 
wire, the server sends the pong.





type='get'>

  




type='result'/>




###

Thoughts?

Peter

--
Peter Saint-Andre
https://andyet.com/