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

Ruslan N. Marchenko me at ruff.mobi
Thu Feb 9 09:29:08 UTC 2017



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 at 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 <csi> 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 <delayed/> 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-unsubscribe at xmpp.org
> _______________________________________________
>



More information about the Standards mailing list