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 [email protected] 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: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
