moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 15:48:52 -05:00
Code Issues Releases Wiki Activity

Merge pull request #107 from xsf/xep-0352-v0.2

Browse Source 
XEP-0352 v0.2: Explain how CSI is affected by in order processing
This commit is contained in:
Matthew A. Miller 2015-10-02 09:24:51 -06:00
commit e8bb493df5
1 changed files with 28 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
xep-0352.xml
View File

@ -22,6 +22,12 @@
<supersededby/> <supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname> <shortname>NOT_YET_ASSIGNED</shortname>
&mwild; &mwild;
<revision>
<version>0.2</version>
<date>2015-10-02</date>
<initials>XEP Editor (mam)</initials>
<remark><p>Clarified how CSI is affected by in-order processing (Florian Schmaus).</p></remark>
</revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2014-08-28</date> <date>2014-08-28</date>
@ -117,6 +123,28 @@
<p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of <p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of
the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the
fully standard behaviour of XMPP is required.</p> fully standard behaviour of XMPP is required.</p>
<section2 topic="In-order processing" anchor="in-order-processing">
<p>
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.
</p>
<p>
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.
</p>
<example caption='In-order processing'><![CDATA[
<!-- Client sends 'active' and a ping to the server -->
<active xmlns='urn:xmpp:csi:0'/>
<iq to='capulaet.lit' from='juliet@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@capulet.lit/baclony' from='capulet.lit' id='ping1' type='result'/>
<!-- Stream state is now 'active' -->]]></example>
</section2>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other <p>To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other