moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

corrections based on feedback from Alexey Melnikov 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3259 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-06-11 23:26:36 +00:00
parent 44d58576a4
commit b3aed96d78
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0198.xml
View File

@ -171,7 +171,7 @@ S: <stream:features>
C: <enable xmlns='urn:xmpp:sm:2'/>
]]></example>
<p>If the initiating entity wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;. For information about resuming a previous session, see the <link url='#resumption'>Resumption</link> section of this document.</p>
<p>The &lt;enable/&gt; element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time.</p>
<p>The &lt;enable/&gt; element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time in seconds.</p>
<p>The &lt;enable/&gt; element MAY include a 'stanzas' attribute to specify the initiating entity's preferred number of stanzas between acks.</p>
<p>Upon receiving the enable request, the receiving entity MUST reply with an &lt;enabled/&gt; element or a &lt;failed/&gt; element qualified by the 'urn:xmpp:sm:2' namespace. The &lt;failed/&gt; element indicates that there was a problem establishing the stream management "session". The &lt;enabled/&gt; element indicates successful establishment of the stream management session.</p>
<example caption='Server enables stream management'><![CDATA[
@ -240,7 +240,7 @@ C: <enable xmlns='urn:xmpp:sm:2' resume='true'/>
<example caption='Server allows stream resumption'><![CDATA[
S: <enabled xmlns='urn:xmpp:sm:2' id='some-long-sm-id' resume='true'/>
]]></example>
<p class='def'><strong>Definition:</strong> The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (as long as the receiving entity is available). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
<p class='def'><strong>Definition:</strong> The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
<p>If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the receiving entity. The order of events is as follows:</p>
<ol start='1'>
<li>Initiating entity sends initial stream header.</li>
@ -272,7 +272,7 @@ S: <resumed xmlns='urn:xmpp:sm:2'
]]></example>
<p>If the receiving entity does not support session resumption, it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &feature;. If the receiving entity does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &notfound;. In both of these failure cases, the receiving entity SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream negotiation process and re-authenticate.</p>
<p>If the former stream is resumed and the receiving entity still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.</p>
<p>When a session is resumed, the parties SHOULD proceed as follows:</p>
<p>When a session is resumed, the parties proceed as follows:</p>
<ul>
<li>Both parties SHOULD retransmit any stanzas that were not handled during the previous session, based on the sequence number reported by the peer.</li>
<li>A reconnecting client SHOULD NOT request the roster, because any roster changes that occurred while the client was disconnected will be sent to the client after the stream management session resumes.</li>
@ -338,7 +338,7 @@ C: <r xmlns='urn:xmpp:sm:2'/>
]]></example>
<p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then returns the roster.</p>
<example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
S: <a xmlns='urn:xmpp:sm:2' h='0'/>
S: <a xmlns='urn:xmpp:sm:2' h='1'/>
S: <iq id='ls72g593' type='result'>
<query xmlns='jabber:iq:roster'>
@ -358,7 +358,7 @@ C: <r xmlns='urn:xmpp:sm:2'/>
]]></example>
<p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then broadcasts the user's presence (including to the client itself as shown below).</p>
<example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
S: <a xmlns='urn:xmpp:sm:2' h='1'/>
S: <a xmlns='urn:xmpp:sm:2' h='2'/>
S: <presence from='romeo@montague.lit/orchard'
to='romeo@montague.lit/orchard'/>
@ -375,7 +375,7 @@ C: <r xmlns='urn:xmpp:sm:2'/>
]]></example>
<p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then routes the stanza to the remote contact (not shown here because the server does not send a stanza to the client).</p>
<example caption='Server acknowledges handling of the stanza'><![CDATA[
S: <a xmlns='urn:xmpp:sm:2' h='2'/>
S: <a xmlns='urn:xmpp:sm:2' h='3'/>
]]></example>
<p>And so on.</p>
</section2>
@ -617,7 +617,7 @@ S: <t stanzas='10'/>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Dave Cridland, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.</p>
<p>Thanks to Dave Cridland, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Alexey Melnikov, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.</p>
</section1>
</xep>