[Standards] LAST CALL: XEP-0352 (Client State Indication)

Kevin Smith kevin.smith at isode.com
Wed Sep 23 12:27:02 UTC 2015


On 22 Sep 2015, at 21:53, Peter Saint-Andre - &yet <peter at 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 at 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='juliet at capulet.lit <mailto:from='juliet at 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='juliet at capulet.lit <mailto:to='juliet at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150923/a3b64bd2/attachment.html>


More information about the Standards mailing list