mirror of https://github.com/moparisthebest/xeps
XEP-0198: Fix example formatting
Remove trailing whitespace
This commit is contained in:
Sam Whited
parent
395d3b77c3
commit
fb27ff2073
293
xep-0198.xml
293
xep-0198.xml
|
|
@ -16,8 +16,8 @@
|
|||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes>None</supersedes>
|
||||
<supersededby>None</supersededby>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>sm</shortname>
|
||||
<schemaloc>
|
||||
<url>http://xmpp.org/schemas/sm.xsd</url>
|
||||
|
|
@ -28,6 +28,12 @@
|
|||
&fabio;
|
||||
&dcridland;
|
||||
&mwild;
|
||||
<revision>
|
||||
<version>1.5.1</version>
|
||||
<date>2016-09-30</date>
|
||||
<initials>ssw</initials>
|
||||
<remark><p>Fix example syntax highlighting and formatting.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.5</version>
|
||||
<date>2015-09-13</date>
|
||||
|
|
@ -199,56 +205,55 @@
|
|||
</ul>
|
||||
<p>Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in <cite>RFC 6120</cite>) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.</p>
|
||||
<p>Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see <cite>RFC 6120</cite>), &xep0199;, or TCP keepalives. By contrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.</p>
|
||||
<p>Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams. (In this document, examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server.)</p>
|
||||
<p>Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Stream Feature' anchor='feature'>
|
||||
<p>The server returns a stream header to the client along with stream features, where the features include an <sm/> element qualified by the 'urn:xmpp:sm:3' namespace &VNOTE;.</p>
|
||||
<p>Note: The client cannot negotiate stream management until it has authenticated with the server and has bound a resource; see below for specific restrictions.</p>
|
||||
<example caption='Server sends new stream header along with stream features'><![CDATA[
|
||||
S: <stream:stream
|
||||
from='example.com'
|
||||
xmlns='jabber:client'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'
|
||||
version='1.0'>
|
||||
<stream:stream
|
||||
from='example.com'
|
||||
xmlns='jabber:client'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'
|
||||
version='1.0'>
|
||||
|
||||
S: <stream:features>
|
||||
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
||||
<sm xmlns='urn:xmpp:sm:3'/>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
<stream:features>
|
||||
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
||||
<sm xmlns='urn:xmpp:sm:3'/>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Enabling Stream Management' anchor='enable'>
|
||||
<p>To enable use of stream management, the client sends an <enable/> command to the server.</p>
|
||||
<example caption='Client enables stream management'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<enable xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>If the client 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 client's preferred maximum resumption time in seconds.</p>
|
||||
<p>Upon receiving the enable request, the server MUST reply with an <enabled/> element or a <failed/> element qualified by the 'urn:xmpp:sm:3' 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[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<enabled xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The parties can then the use stream management features defined below.</p>
|
||||
<p>If the server allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1" &BOOLEANNOTE;.</p>
|
||||
<example caption='Server enables stream management with session resumption'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
|
||||
]]></example>
|
||||
<enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
|
||||
]]></example>
|
||||
<p>The <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.</p>
|
||||
<p>The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of <cite>RFC 6120</cite> (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in <cite>RFC 6120</cite> applies.</p>
|
||||
<p>The client MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.</p>
|
||||
<p>For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding <em>unless it is resuming a previous session</em> (see <link url='#resumption'>Resumption</link>).</p>
|
||||
<p>The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see <link url='#errors'>Error Handling</link>).</p>
|
||||
<example caption='Server returns error if client attempts to enable stream management before resource binding'><![CDATA[
|
||||
S: <failed xmlns='urn:xmpp:sm:3'>
|
||||
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</failed>
|
||||
]]></example>
|
||||
<p>Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second <enable/> element it SHOULD respond with a stream error, thus terminating the client connection
|
||||
.</p>
|
||||
<failed xmlns='urn:xmpp:sm:3'>
|
||||
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</failed>
|
||||
]]></example>
|
||||
<p>Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second <enable/> element it SHOULD respond with a stream error, thus terminating the client connection.</p>
|
||||
</section1>
|
||||
|
||||
|
||||
<section1 topic='Acks' anchor='acking'>
|
||||
<p>After enabling stream management, the client or server can send ack elements at any time over the stream. An ack element is one of the following:</p>
|
||||
<ul>
|
||||
|
|
@ -267,35 +272,39 @@ S: <failed xmlns='urn:xmpp:sm:3'>
|
|||
<p class='box'>Note: There are two values of 'h' for any given stream: one maintained by the client to keep track of stanzas it has handled from the server, and one maintained by the server to keep track of stanzas it has handled from the client. The client initializes its value to zero when it sends <enable/> to the server, and the server initializes its value to zero when it sends <enabled/> to the client (it is expected that the server will respond immediately to <enable/> and set its counter to zero at that time). After this initialization, the client increments its value of 'h' for each stanza it handles from server, and the server increments its value of 'h' for each stanza it handles from the client.</p>
|
||||
<p>The following annotated example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.</p>
|
||||
<example caption='Simple stanza acking'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3'/>
|
||||
<!-- Client -->
|
||||
<enable xmlns='urn:xmpp:sm:3'/>
|
||||
|
||||
<!-- Client sets outbound count to zero. -->
|
||||
<!-- Client sets outbound count to zero. -->
|
||||
|
||||
C: <message from='laurence@example.net/churchyard'
|
||||
to='juliet@example.com'
|
||||
xml:lang='en'>
|
||||
<body>
|
||||
I'll send a friar with speed, to Mantua,
|
||||
with my letters to thy lord.
|
||||
</body>
|
||||
</message>
|
||||
<message from='laurence@example.net/churchyard'
|
||||
to='juliet@example.com'
|
||||
xml:lang='en'>
|
||||
<body>
|
||||
I'll send a friar with speed, to Mantua,
|
||||
with my letters to thy lord.
|
||||
</body>
|
||||
</message>
|
||||
|
||||
<!-- Note that client need not wait for a response. -->
|
||||
<!-- Note that client need not wait for a response. -->
|
||||
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'/>
|
||||
<!-- Server -->
|
||||
<enabled xmlns='urn:xmpp:sm:3'/>
|
||||
|
||||
<!--
|
||||
Server receives enable, and responds,
|
||||
setting both inbound and outbound counts
|
||||
to zero.
|
||||
|
||||
In addition, client sets inbound count to zero.
|
||||
-->
|
||||
<!--
|
||||
Server receives enable, and responds,
|
||||
setting both inbound and outbound counts
|
||||
to zero.
|
||||
|
||||
C: <r xmlns='urn:xmpp:sm:3'/>
|
||||
In addition, client sets inbound count to zero.
|
||||
-->
|
||||
|
||||
S: <a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
]]></example>
|
||||
<!-- Client -->
|
||||
<r xmlns='urn:xmpp:sm:3'/>
|
||||
|
||||
<!-- Server -->
|
||||
<a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
]]></example>
|
||||
<p>When an <r/> element ("request") is received, the recipient MUST acknowledge it by sending an <a/> element to the sender containing a value of 'h' that is equal to the number of stanzas handled by the recipient of the <r/> element. The response SHOULD be sent as soon as possible after receiving the <r/> element, and MUST NOT be withheld for any condition other than a timeout. For example, a client with a slow connection might want to collect many stanzas over a period of time before acking, and a server might want to throttle incoming stanzas. The sender does not need to wait for an ack to continue sending stanzas.</p>
|
||||
<p>Either party MAY send an <a/> element at any time (e.g., after it has received a certain number of stanzas, or after a certain period of time), even if it has not received an <r/> element from the other party.</p>
|
||||
<p>When a party receives an <a/> element, it SHOULD keep a record of the 'h' value returned as the sequence number of the last handled outbound stanza for the current stream (and discard the previous value).</p>
|
||||
|
|
@ -312,20 +321,20 @@ S: <a xmlns='urn:xmpp:sm:3' h='1'/>
|
|||
<p>In addition, this protocol exchanges the sequence numbers of the last received stanzas on the previous connection, allowing entities to establish definitively which stanzas require retransmission and which do not, eliminating duplication through replay.</p>
|
||||
<p>To request that the stream will be resumable, when enabling stream management the client MUST add a 'resume' attribute to the <enable/> element with a value of "true" or "1" &BOOLEANNOTE;.</p>
|
||||
<example caption='Client enables stream management'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3' resume='true'/>
|
||||
]]></example>
|
||||
<enable xmlns='urn:xmpp:sm:3' resume='true'/>
|
||||
]]></example>
|
||||
<p>If the server will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the <enabled/> element and MUST include an 'id' attribute that specifies an identifier for the stream.</p>
|
||||
<example caption='Server allows stream resumption'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
|
||||
]]></example>
|
||||
<enabled xmlns='urn:xmpp:sm:3' 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 server. The client MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The server 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>As noted, the <enabled/> element MAY include a 'location' attribute that specifies the server's preferred location for reconnecting (e.g., a particular connection manager that hold session state for the connected client).</p>
|
||||
<example caption='Server prefers reconnection at a particular location'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'
|
||||
<enabled xmlns='urn:xmpp:sm:3'
|
||||
id='some-long-sm-id'
|
||||
location='[2001:41D0:1:A49b::1]:9222'
|
||||
resume='true'/>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>If the stream is terminated unexpectedly, the client would then open a TCP connection to the server. The order of events is as follows:</p>
|
||||
<ol start='1'>
|
||||
<li>After disconnection, the client opens a new TCP connection to the server, preferring the address specified in the 'location' attribute (if any).</li>
|
||||
|
|
@ -347,23 +356,23 @@ S: <enabled xmlns='urn:xmpp:sm:3'
|
|||
<p>Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in <cite>RFC 6120</cite>. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.</p>
|
||||
<p>To request resumption of the former stream, the client sends a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MUST include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the client (in the unlikely case that the client never received any stanzas, it would set 'h' to zero).</p>
|
||||
<example caption='Stream resumption request'><![CDATA[
|
||||
C: <resume xmlns='urn:xmpp:sm:3'
|
||||
h='some-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<resume xmlns='urn:xmpp:sm:3'
|
||||
h='some-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<p>If the server can resume the former stream, it MUST return a <resumed/> element, which MUST include a 'previd' attribute set to the SM-ID of the former stream and MUST also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the client to the server (in the unlikely case that the server never received any stanzas, it would set 'h' to zero).</p>
|
||||
<example caption='Stream resumed'><![CDATA[
|
||||
S: <resumed xmlns='urn:xmpp:sm:3'
|
||||
h='another-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<resumed xmlns='urn:xmpp:sm:3'
|
||||
h='another-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<p>If the server does not support session resumption, it MUST return a <failed/> element, which SHOULD include an error condition of &feature;. If the server 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;. If the server recogizes the 'previd' as an earlier session that has timed out the server MAY also include a 'h' attribute indicating the number of stanzas received before the timeout. (Note: For this to work the server has to store the SM-ID/sequence number tuple past the time out of the actual session.)</p>
|
||||
<example caption='Stream timed out'><![CDATA[
|
||||
S: <failed xml='urn:xmpp:sm:3'
|
||||
h='another-sequence-number'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</failed>
|
||||
]]></example>
|
||||
<failed xml='urn:xmpp:sm:3'
|
||||
h='another-sequence-number'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</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>When a session is resumed, the parties proceed as follows:</p>
|
||||
|
|
@ -381,10 +390,10 @@ S: <failed xml='urn:xmpp:sm:3'
|
|||
<p>If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in <cite>RFC 6120</cite>.</p>
|
||||
<p>An example follows.</p>
|
||||
<example caption='Server returns error'><![CDATA[
|
||||
S: <failed xmlns='urn:xmpp:sm:3'>
|
||||
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</failed>
|
||||
]]></example>
|
||||
<failed xmlns='urn:xmpp:sm:3'>
|
||||
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</failed>
|
||||
]]></example>
|
||||
<p>Stream management errors SHOULD be considered recoverable; however, misuse of stream management MAY result in termination of the stream.</p>
|
||||
</section1>
|
||||
|
||||
|
|
@ -408,83 +417,89 @@ S: <failed xmlns='urn:xmpp:sm:3'>
|
|||
<p>The following examples illustrate basic acking (here the client automatically acks each stanza it has received from the server, without first being prompted via an <r/> element).</p>
|
||||
<p>First, after authentication and resource binding, the client enables stream management.</p>
|
||||
<example caption='Client enables stream management'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<enable xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The server then enables stream management.</p>
|
||||
<example caption='Server enables stream management'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<enabled xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The client then retrieves its roster and immediately sends an <r/> element to request acknowledgement.</p>
|
||||
<example caption='Client sends a stanza and requests acknowledgement'><![CDATA[
|
||||
C: <iq id='ls72g593' type='get'>
|
||||
<query xmlns='jabber:iq:roster'/>
|
||||
</iq>
|
||||
<iq id='ls72g593' type='get'>
|
||||
<query xmlns='jabber:iq:roster'/>
|
||||
</iq>
|
||||
|
||||
C: <r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The server handles the client stanza (here returning the roster) and sends an <a/> element to acknowledge handling of the stanza.</p>
|
||||
<example caption='Server handles client stanza and acknowledges handling of client stanza'><![CDATA[
|
||||
S: <iq id='ls72g593' type='result'>
|
||||
<query xmlns='jabber:iq:roster'>
|
||||
<item jid='juliet@capulet.lit'/>
|
||||
<item jid='benvolio@montague.lit'/>
|
||||
</query>
|
||||
</iq>
|
||||
<iq id='ls72g593' type='result'>
|
||||
<query xmlns='jabber:iq:roster'>
|
||||
<item jid='juliet@capulet.lit'/>
|
||||
<item jid='benvolio@montague.lit'/>
|
||||
</query>
|
||||
</iq>
|
||||
|
||||
S: <a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
]]></example>
|
||||
<a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
]]></example>
|
||||
<p>The client then chooses to acknowledge receipt of the server's stanza (although here it is under no obligation to do so, since the server has not requested an ack), sends initial presence, and immediately sends an <r/> element to request acknowledgement, incrementing by one its internal representation of how many stanzas have been handled by the server.</p>
|
||||
<example caption='Client acks handling of first server stanza, sends a stanza, and requests acknowledgement'><![CDATA[
|
||||
C: <a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
<a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
|
||||
C: <presence/>
|
||||
<presence/>
|
||||
|
||||
C: <r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></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 acks handling of second client stanza and sends a stanza'><![CDATA[
|
||||
S: <a xmlns='urn:xmpp:sm:3' h='2'/>
|
||||
<a xmlns='urn:xmpp:sm:3' h='2'/>
|
||||
|
||||
S: <presence from='romeo@montague.lit/orchard'
|
||||
to='romeo@montague.lit/orchard'/>
|
||||
]]></example>
|
||||
<presence from='romeo@montague.lit/orchard'
|
||||
to='romeo@montague.lit/orchard'/>
|
||||
]]></example>
|
||||
<p>The client then acks the server's second stanza and sends an outbound message followed by an <r/> element.</p>
|
||||
<example caption='Client acks receipt of second server stanza, sends a stanza, and requests acknowledgement'><![CDATA[
|
||||
C: <a xmlns='urn:xmpp:sm:3' h='2'/>
|
||||
<a xmlns='urn:xmpp:sm:3' h='2'/>
|
||||
|
||||
C: <message to='juliet@capulet.lit'>
|
||||
<body>ciao!</body>
|
||||
</message>
|
||||
<message to='juliet@capulet.lit'>
|
||||
<body>ciao!</body>
|
||||
</message>
|
||||
|
||||
C: <r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<r xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The server immediately sends an <a/> element to acknowledge handling of the third client 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 third client stanza'><![CDATA[
|
||||
S: <a xmlns='urn:xmpp:sm:3' h='3'/>
|
||||
]]></example>
|
||||
<a xmlns='urn:xmpp:sm:3' h='3'/>
|
||||
]]></example>
|
||||
<p>And so on.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Efficient Acking Scenario' anchor='scenarios-efficient'>
|
||||
<p>The basic acking scenario is wasteful because the client requested an ack for each stanza. A more efficient approach is to periodically request acks (e.g., every 5 stanzas). This is shown schematically in the following pseudo-XML.</p>
|
||||
<example caption='An efficient session'><![CDATA[
|
||||
C: <enable/>
|
||||
S: <enabled/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <r/>
|
||||
S: <a h='5'/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <message/>
|
||||
C: <r/>
|
||||
S: <a h='10'/>
|
||||
]]></example>
|
||||
<!-- Client -->
|
||||
<enable/>
|
||||
<!-- Server -->
|
||||
<enabled/>
|
||||
<!-- Client -->
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<r/>
|
||||
<!-- Server -->
|
||||
<a h='5'/>
|
||||
<!-- Client-->
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<message/>
|
||||
<r/>
|
||||
<!-- Server -->
|
||||
<a h='10'/>
|
||||
]]></example>
|
||||
<p>In particular, on mobile networks, it is advisable to only request and/or send acknowledgements when an entity has other data to send, or in lieu of a whitespace keepalive or XMPP ping (XEP-0199).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
|
@ -537,8 +552,8 @@ S: <a h='10'/>
|
|||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='h'
|
||||
type='xs:integer'
|
||||
<xs:attribute name='h'
|
||||
type='xs:integer'
|
||||
use='required'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
|
|
@ -549,10 +564,10 @@ S: <a h='10'/>
|
|||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='max'
|
||||
type='xs:positiveInteger'
|
||||
<xs:attribute name='max'
|
||||
type='xs:positiveInteger'
|
||||
use='optional'/>
|
||||
<xs:attribute name='resume'
|
||||
<xs:attribute name='resume'
|
||||
type='xs:boolean'
|
||||
use='optional'
|
||||
default='false'/>
|
||||
|
|
@ -565,16 +580,16 @@ S: <a h='10'/>
|
|||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='id'
|
||||
<xs:attribute name='id'
|
||||
type='xs:string'
|
||||
use='optional'/>
|
||||
<xs:attribute name='location'
|
||||
type='xs:string'
|
||||
<xs:attribute name='location'
|
||||
type='xs:string'
|
||||
use='optional'/>
|
||||
<xs:attribute name='max'
|
||||
type='xs:positiveInteger'
|
||||
<xs:attribute name='max'
|
||||
type='xs:positiveInteger'
|
||||
use='optional'/>
|
||||
<xs:attribute name='resume'
|
||||
<xs:attribute name='resume'
|
||||
type='xs:boolean'
|
||||
use='optional'
|
||||
default='false'/>
|
||||
|
|
@ -585,13 +600,13 @@ S: <a h='10'/>
|
|||
|
||||
<xs:element name='failed'>
|
||||
<xs:complexType>
|
||||
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'
|
||||
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'
|
||||
minOccurs='0'
|
||||
maxOccurs='1'>
|
||||
<xs:group ref='err:stanzaErrorGroup'/>
|
||||
</xs:sequence>
|
||||
<xs:attribute name='h'
|
||||
type='xs:unsignedInt'
|
||||
<xs:attribute name='h'
|
||||
type='xs:unsignedInt'
|
||||
use='optional'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
|
@ -614,11 +629,11 @@ S: <a h='10'/>
|
|||
<xs:complexType name='resumptionElementType'>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='h'
|
||||
type='xs:unsignedInt'
|
||||
<xs:attribute name='h'
|
||||
type='xs:unsignedInt'
|
||||
use='required'/>
|
||||
<xs:attribute name='previd'
|
||||
type='xs:string'
|
||||
<xs:attribute name='previd'
|
||||
type='xs:string'
|
||||
use='required'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
|
|
|
|||
Loading…
Reference in New Issue