On 22 Sep 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 
> <mailto: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 <mailto:to='jul...@capulet.lit>/baclony' 
> from='capulet.lit' id='ping1' type='result'/>
> 
> <!-- Stream state is now 'active' -->
> 
> ###
> 
> Thoughts?

That text seems consistent with in-order processing requirements, so it doesn’t 
hurt to spell it out.

/K

Reply via email to