On 23.09.2015 17:29, Matthew Wild wrote: > On 22 September 2015 at 21:53, Peter Saint-Andre - &yet > <pe...@andyet.net> 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 standards@xmpp.org 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='jul...@capulet.lit/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='jul...@capulet.lit/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 :)
It does, the ping result basically acts as notification that the stream state change has been completed. Thanks to everyone working on this. - Florian
signature.asc
Description: OpenPGP digital signature
