On 22 September 2015 at 21:53, Peter Saint-Andre - &yet <[email protected]> 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 [email protected] 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 &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 --> > > <active xmlns='urn:xmpp:csi:0'/> > <iq to='capulaet.lit' from='[email protected]/balcony' id='ping1' > type='get'> > <ping xmlns='urn:xmpp:ping'/> > </iq> > > <!-- 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='[email protected]/baclony' from='capulet.lit' id='ping1' > type='result'/> > > <!-- Stream state is now 'active' --> > > ### > > 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
