From 79bb7b34c6fa887dcf98877c9c8d4704bc75e3f5 Mon Sep 17 00:00:00 2001 From: stpeter Date: Wed, 20 Apr 2011 08:48:27 -0600 Subject: [PATCH] 1.3rc1 --- xep-0198.xml | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/xep-0198.xml b/xep-0198.xml index e1ea87ce..93948e0e 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -11,6 +11,7 @@ &LEGALNOTICE; 0198 Draft + Standards Track Standards @@ -28,6 +29,12 @@ &fabio; &dcridland; &mwild; + + 1.3rc1 + in progress, last updated 2011-04-20 + psa/mw +

Corrected the value of 'h' in several examples; removed an extraneous 'stanzas' attribute from one example.

 + 1.2 2011-03-02 @@ -376,10 +383,8 @@ C: C: ]]> -

The server immediately sends an <a/> element to acknowledge handling of the stanza and then returns the roster.

- - +

The server handles the client stanza (here returning the roster) and sends an <a/> element to acknowledge handling of the stanza.

+ @@ -387,25 +392,26 @@ S: +S: ]]> -

The client then acknowledges receipt of the server's stanza, 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.

- +

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.

+ C: C: ]]>

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).

- S: ]]>

The client then acks the server's second stanza and sends an outbound message followed by an <r/> element.

- + C: ciao! @@ -413,32 +419,32 @@ C: C: ]]> -

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).

- 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).

+ ]]>

And so on.

-

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) in accordance with the 'stanzas' attribute value provided by the receiving entity on the <enabled/> element. This is shown schematically in the following pseudo-XML.

+

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.

-S: +S: C: C: C: C: C: C: -S: +S: C: C: C: C: C: C: -S: +S: ]]>

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).