From fb27ff2073736101c6c7a5ed5edd69c85c5debb4 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Fri, 30 Sep 2016 14:51:45 -0500 Subject: [PATCH] XEP-0198: Fix example formatting Remove trailing whitespace --- xep-0198.xml | 293 +++++++++++++++++++++++++++------------------------ 1 file changed, 154 insertions(+), 139 deletions(-) diff --git a/xep-0198.xml b/xep-0198.xml index 62bceb29..b3b1e5b9 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -16,8 +16,8 @@ XMPP Core - None - None + + sm http://xmpp.org/schemas/sm.xsd @@ -28,6 +28,12 @@ &fabio; &dcridland; &mwild; + + 1.5.1 + 2016-09-30 + ssw +

Fix example syntax highlighting and formatting.

 + 1.5 2015-09-13 @@ -199,56 +205,55 @@

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 RFC 6120) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.

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 RFC 6120), &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.

-

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

+

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.

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

Note: The client cannot negotiate stream management until it has authenticated with the server and has bound a resource; see below for specific restrictions.

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

To enable use of stream management, the client sends an <enable/> command to the server.

- ]]> + +]]>

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 Resumption section of this document.

The <enable/> element MAY include a 'max' attribute to specify the client's preferred maximum resumption time in seconds.

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.

- ]]> + +]]>

The parties can then the use stream management features defined below.

If the server allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1" &BOOLEANNOTE;.

- ]]> + +]]>

The <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.

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 RFC 6120 (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 RFC 6120 applies.

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.

For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding unless it is resuming a previous session (see Resumption).

The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see Error Handling).

- - - ]]> -

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

+ + + +]]> +

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.

 - +

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: