mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 02:02:16 -05:00
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:
parent
44d58576a4
commit
b3aed96d78
14
xep-0198.xml
14
xep-0198.xml
@ -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 <enable/> element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time.</p>
|
||||
<p>The <enable/> element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time in seconds.</p>
|
||||
<p>The <enable/> 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 <enabled/> element or a <failed/> element qualified by the 'urn:xmpp:sm:2' namespace. The <failed/> element indicates that there was a problem establishing the stream management "session". The <enabled/> 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 <failed/> 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 <failed/> element, which SHOULD include an error condition of ¬found;. 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 <a/> 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 <a/> 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 <a/> 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>
|
||||
|
Loading…
Reference in New Issue
Block a user