<p>&rfc6120; specifies that XMPP servers and clients can send whitespace characters between first-level elements of an XML stream as a way to maintain the state of the stream. These "whitespace keepalives" are widely used on the XMPP network. However, currently it is not possible to negotiate the frequency of sending keepalives, or even whether to send keepalives at all (the server simply sends them according to its own schedule). Because certain kinds of devices might not want to use keepalives, or might wish to receive keepalives more frequently or less frequently than the server's default, this specification defines a method for negotiating how to send whitespace keepalives between an XMPP server and an XMPP client (this method could also be used between two servers, although that usage is expected to be rare).</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<p>The protocol defined in this document enables a client negotiate the time interval between whitespace keepalives, within a range determined by the server. Normally, the client starts the negotiation since not all kinds of the client support the feature.</p>
<p>The protocol defines a keepalive element and the normal negotaition process is quite simple, demonstrated as following:</p>
<olstart='1'>
<li>Server announces keepalive feature with a range of time intervals.</li>
<li>Client starts the keepalive negotiation by specifying a time interval. </li>
<li>Server checks the value and relpies with success or failure.</li>
</ol>
<p>Then server and client send whitespace keepalive to each other at the agreed time interval.</p>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<section2topic='Stream Feature'anchor='feature'>
<p>During the stream negotiation process, the server can advertise this feature. The feature is negotiated after the resource binding. (See &xep0170; regarding the recommended order of stream feature negotiation.)</p>
<examplecaption='Server lists feature in the stream negotiation stage'><![CDATA[
<p>Client negotiates the keepalive feature by providing an interval value based on server limits and its own condition. The interval SHOULD be a positive interger, and zero is invalid.</p>
<p>Then both the server and the client send whitespace keepalives at the interval of the negotiated value. The server SHOULD check to see if has received keepalives and MAY drop the connection if it has not received a keepalive for a period of time significantly longer than the negotiated value (the client MAY also implement this behavior).</p>
<li>Both parties SHOULD keep a record of the keepalive status and honor the negotiated value when allowing stream resumption and session recreation. See &xep0198;</li>
<li>The length of the keepalive interval depends on the service type and network environment. Implementations are encouraged to use appropriate values based on implementation and deployment experience.</li>