XEP-0304: Whitespace Keepalive Negotiation

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

RFC 6120 [1] 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).

2. Protocol

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.

3. Use Cases

C: <stream:stream 
           to='example.com' 
           version='1.0' 
           xmlns='jabber:client' 
           xmlns:stream='http://etherx.jabber.org/streams'>
 
C: <stream:stream 
           from='example.com' 
           id='KskA2O2BEn5mL7mABTq9X3DTPHO44vAMaIg1nG9O1vo'
           version='1.0' 
           xmlns='jabber:client' 
           xmlns:stream='http://etherx.jabber.org/streams'>
S:  <stream:features>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
        <keepalive xmlns='urn:xmpp:keepalive:0'>
          <interval min='60' max='300'/> 
        </keepalive>
    </stream:features>
    

<iq from='client@example.com/foo' id='p03ns61g' to='example.com' type='set'>
  <keepalive xmlns='urn:xmpp:keepalive:0'>
    <interval>60</interval>
  </keepalive>
</iq>
    

<iq from='example.com' id='p03ns61g' to='client@example.com/foo' type='result'/>
    

<iq from='example.com' id='p03ns61g' to='client@example.com/foo' type='error'>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

4. Implementation Notes

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 Stream Management [3]
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.

5. Security Considerations

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

6. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

7. XMPP Registrar Considerations

8. XML Schema

<?xml version='1.0' encoding='utf-8'?>

<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'
            targetNamespace='urn:xmpp:keepalive:0'
            xmlns='urn:xmpp:keepalive:0'
            elementFormDefault='unqualified'>
  
  <xsd:element name='keepalive'>
    <xsd:complexType>
      <xsd:attribute name='min' type='positiveShort' use='optional'/>
      <xsd:attribute name='max' type='positiveShort' use='optional'/>
      <xsd:assert test='@min le @max'/>
      <xsd:element name='interval' type='positiveShort' minOccurs='0' maxOccurs='1'/>
    </xsd:complexType>
  </xsd:element>

  <xsd:simpleType name='positiveShort'>
    <xsd:restriction base='xsd:unsignedShort'>
      <xsd:minExclusive value='0'/>
    </xsd:restriction>
  </xsd:simpleType>

</xsd:schema>

  

9. Acknowledgements

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

Appendices

Appendix A: Document Information

Series: XEP
Number: 0304
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2011-08-18
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END