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

Florian Schmaus flo at geekplace.eu
Wed Sep 23 16:00:03 UTC 2015


On 23.09.2015 17:29, Matthew Wild wrote:
> On 22 September 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/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/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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150923/1a4cab1a/attachment.sig>


More information about the Standards mailing list