[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?
> 3. Do you plan to implement this specification in your code? If not, why not?
> 4. Do you have any security concerns related to this specification?
> 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
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