moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Merge commit 'refs/pull/579/head' of https://github.com/xsf/xeps

Browse Source
This commit is contained in:
Jonas Schäfer 2018-11-08 20:28:14 +01:00
commit 5cf403c4c3
1 changed files with 40 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
xep-0198.xml
View File

@ -28,6 +28,12 @@
&fabio;
&dcridland;
&mwild;
<revision>
<version>1.6</version>
<date>2018-07-25</date>
<initials>gdk</initials>
<remark><p>Specify error conditions.</p></remark>
</revision>
<revision>
<version>1.5.4</version>
<date>2018-07-19</date>
@ -270,6 +276,11 @@
</failed>
]]></example>
<p>Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second &lt;enable/> element it SHOULD respond with a stream error, thus terminating the client connection.</p>
<example caption='Server returns error if client attempts to enable stream management more than once'><![CDATA[
<failed xmlns='urn:xmpp:sm:3'>
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
]]></example>
</section1>
<section1 topic='Acks' anchor='acking'>
@ -394,7 +405,13 @@
</failed>
]]></example>
<p>In both of these failure cases, the server SHOULD allow the client to bind a resource at this point rather than forcing the client to restart the stream negotiation process and re-authenticate.</p>
<p>If the former stream is resumed and the server still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.</p>
<p>If the former stream is resumed and the server still has the stream for the previously-identified session open at this time, the server SHOULD send a 'conflict' stream error and close that stream.</p>
<example caption='Server closes old stream that was replaced by new'><![CDATA[
<stream:error>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
]]></example>
<p>When a session is resumed, the parties proceed as follows:</p>
<ul>
<li>The sequence values are carried over from the previous session and are not reset for the new stream.</li>
@ -415,6 +432,17 @@
</failed>
]]></example>
<p>Stream management errors SHOULD be considered recoverable; however, misuse of stream management MAY result in termination of the stream.</p>
<p>When a remote entity acknowledges that it has handled a number of stanzas that is higher than the amount of stanzas that it was sent (by sending an 'h' value that is too high), the local entity SHOULD generate an undefined-condition stream error that includes a &lt;handled-count-too-high/&gt; element, and close the stream:</p>
<example caption='Entity closes stream because peer acknowledges more stanzas than it was sent'><![CDATA[
<stream:error>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<handled-count-too-high xmlns='urn:xmpp:sm:3' h='10' send-count='8'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
You acknowledged 10 stanzas, but I only sent you 8 so far.
</text>
</stream:error>
</stream:stream>
]]></example>
</section1>
<section1 topic='Stream Closure' anchor='closure'>
@ -665,6 +693,17 @@
</xs:restriction>
</xs:simpleType>
<xs:element name='handled-count-too-high'>
<xs:complexType>
<xs:attribute name='send-count'
type='xs:unsignedInt'
use='optional'/>
<xs:attribute name='h'
type='xs:unsignedInt'
use='optional'/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section1>