From ddea3e03f50092d21d3ca262c572d6da4a122dcd Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 10 Apr 2009 00:17:38 +0000 Subject: [PATCH] 0.8 published git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3028 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0198.xml | 192 ++++++++++++++++++++++++++------------------------- 1 file changed, 99 insertions(+), 93 deletions(-) diff --git a/xep-0198.xml b/xep-0198.xml index d848ffef..fc3f26d0 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -25,9 +25,18 @@ &fabio; 0.8 - 2009-04-08 - ff/jk/psa -

Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary); added <t/> element for throttling notifications.

 + 2009-04-09 + ff/jk/jjh/psa + +
    +
  • Added <t/> element for throttling notifications, including 'stanzas' attribute for dynamic adjustment of the stanzas window.
    • +
  • Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary).
    • +
  • Removed 'h' attribute from <r/> element.
    • +
  • Added 'max' and 'stanzas' attributes to both <enable/> and <enabled/> elements, and removed those attributes from the <sm/> element.
    • +
  • Incremented the protocol version from 1 to 2.
    • +
  • Added in-depth usage scenarios.
    • +
+ 0.7 @@ -41,7 +50,7 @@ psa

This is enough of an implementation to minimally satisfy the peer, and allows basic tracking of each outbound stanza. If the stream connection is broken, the application has a queue of unacknowledged stanzas that it can choose to handle appropriately (e.g., warn a human user or silently send after reconnecting).

-

The following examples illustrate basic acking.

+

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

First, after authentication and resource binding, the client enables stream management.

+C: ]]>

The server then enables stream management.

+S: ]]>

The client then retrieves its roster and immediately sends an <r/> element to request acknowledgement.

-C: +C: ]]>

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

- + S: @@ -325,31 +322,34 @@ S: -S: ]]> -

The client then 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 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.

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

The server handles the stanza by broadcasting the user's presence and immediately sends an <a/> element to acknowledge handling of the stanza.

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

The client then sends an outbound message and an <r/> element.

+

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

+ C: ciao! -C: +C: ]]>

The server handles the stanza by routing it to the remote contact and immediately sends an <a/> element to acknowledge handling of the stanza.

+S: ]]>

And so on.

@@ -377,42 +377,45 @@ S: -

As mentioned, many servers will impose rate limiting on clients that send large amounts of traffic. In the following scenario, we assume that the first few messages sent by the client are rather large, so the server voluntarily throttles the client. The server then sends throttling notifications every 30 seconds, dynamically adjusting the maximum number of stanzas between acks as a rough indicator of how serious the throttling is.

+

As mentioned, many servers will impose rate limiting on clients that send large amounts of traffic. In the following scenario, we assume that the first two messages sent by the client are rather large, so the server voluntarily throttles the client. The server then sends throttling notifications every 30 seconds, dynamically adjusting the maximum number of stanzas between acks as a rough indicator of how serious the throttling is.

-S: +S: C: C: C: [throttling kicks in] -S: -[client adjusts its expectations and requests an ack] +S: +[client requests an ack for the first three messages, but +does not send any more messages until throttling ends] C: [client still throttled, server ignores for now] [30 seconds go by] S: [30 seconds go by] S: -C: [backlog starts to ease, server adjusts 'stanzas' value] -S: +S: +[client sends another message just because it can] C: -[server has handled the first 5 messages so it finally replies to ] -S: +[server has handled the first 3 messages so it finally replies to ] +S: C: C: C: -[client has sent 3 messages so requests an ack] +C: +[client has sent 5 messages so requests an ack] C: -[throttling is over, server replies to and sets 'stanzas' back to 5] -S: +[throttling is over, server replies to 2nd and sets 'stanzas' back to 10] +S: +S: ]]> -

To follow.

+

Intermediate proxies MUST pass through all stanzas, else the parties will go out of sync.

 @@ -423,7 +426,7 @@ S:

This specification defines the following XML namespace:

    -
  • urn:xmpp:sm:1
    • +
  • urn:xmpp:sm:2

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

 @@ -431,7 +434,7 @@ S: &NSVER; -

Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:1:feature' to its registry of stream features.

+

Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:2:feature' to its registry of stream features.

 @@ -441,8 +444,8 @@ S: @@ -451,10 +454,16 @@ S: + + @@ -467,10 +476,16 @@ S: + + @@ -497,12 +512,6 @@ S: - - @@ -526,9 +535,6 @@ S: - @@ -557,7 +563,7 @@ S: -

Thanks to Dave Cridland, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.

+

Thanks to Dave Cridland, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.