As specified in &xmppcore;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.

This specification addresses the following requirements:

1. Determining the viability of an XML stream (i.e., its underlying binding) between a client and a server, or between two servers.
2. Determining end-to-end connectivity between any two XMPP entities (e.g., two clients).

The number of "hops" for which the ping tests connectivity depends on how far the pinged entity is from the pinging entity, as shown in the following use cases. However, this specification does not provide per-hop information similar to that provided by the traceroute protocol (&rfc1393;); a future specification may define such functionality for XMPP.

The XMPP ping protocol is extremely simple:

1. The pinging entity sends an IQ-get containing a <ping/> element qualified by the 'urn:xmpp:ping' namespace.
2. The pinged entity returns either an IQ-result (if it supports the namespace) or an IQ-error (if it does not).

If an entity supports the XMPP Ping protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:ping" in response to a &xep0030; information request:

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

Some XMPP clients do not respond to IQ stanzas containing unsupported payloads. Although this is in violation of &xmppcore;, this behavior can result in disconnection of clients that are in fact actively connected to the server.

If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, RFC 6120 requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.

No interaction with &IANA; is necessary as a result of this document.