[Standards] LAST CALL: XEP-0352 (Client State Indication)
Peter Saint-Andre - &yet
peter at andyet.net
Tue Sep 22 20:53:04 UTC 2015
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 at xmpp.org discussion list:
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
>> 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?
> 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 &rfc6120; 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.
<!-- Client sends 'active' and a ping to the server -->
<iq to='capulaet.lit' from='juliet at capulet.lit/balcony' id='ping1'
<!-- Server restores stream state to active,
e.g. by flushing out queued stanzas to the client.
and responds to the ping with a pong -->
<iq to='juliet at capulet.lit/baclony' from='capulet.lit' id='ping1'
<!-- Stream state is now 'active' -->
More information about the Standards