%ents; ]>
Whitespace Keepalive Negotiation This specification defines a method for negotiating how to send keepalives in XMPP. &LEGALNOTICE; 0304 Deferred Standards Track Standards Council XMPP Core NOT_YET_ASSIGNED Ming Ji mingj@cisco.com mingj@cisco.com 0.1 2011-08-18 psa

Initial published version.

 0.0.1 2011-07-19 mj

First draft.

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

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.

The protocol defines a keepalive element and the normal negotaition process is quite simple, demonstrated as following:

  1. Server announces keepalive feature with a range of time intervals.
  2. Client starts the keepalive negotiation by specifying a time interval.
  3. Server checks the value and relpies with success or failure.

Then server and client send whitespace keepalive to each other at the agreed time interval.

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

C: S: ]]>

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.

60 ]]>

The server checks the keepalive interval value and returns a success:

]]>

If a problem occurs, the server returns an error (in this example, the client sent a value outside the range of the server's preferences):

]]>

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

Several things need to be noted:

  1. Both parties SHOULD keep a record of the keepalive status and honor the negotiated value when allowing stream resumption and session recreation. See &xep0198;
  2. 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.

During negotiation, the server MUST check the keepalive interval value and reject any invalid values.

This document requires no interaction with &IANA;.

The ®ISTRAR; is requested to issue an initial namespace 'urn:xmpp:keepalive:0'

The ®ISTRAR; is requested to issue an initial stream feature namespace 'urn:xmpp:keepalive:0'.

 ]]>

Thanks to Matt Miller and Peter Saint-Andre for their feedback.