<abstract>This specification defines a way for an XMPP servers to deliver information for use in push notifications to mobile and other devices.</abstract>
<p>The purpose of push notifications is to inform users of new messages or other pertinent information even when they have no XMPP clients online.</p>
<p>Typically, these notifications are delivered to a user's mobile device, displaying a notice that can trigger opening an XMPP client to continue a conversation or answer a Jingle session request.</p>
<p>There have been several push notification implementations by mobile XMPP client vendors. However, experience has shown that these implementations carried several drawbacks:</p>
<li>Treated the XMPP client and XMPP server as one unified service, such that push notifications only worked using the "official" client.</li>
<li>Proxied a user's session through the client provider's backend services in order to monitor for and trigger push notifications.</li>
</ul>
<p>The goal for this document is to make the generalized case possible, whereby a user may use their XMPP client of choice with their own server of choice. The requirements are thus:</p>
<ul>
<li>Allow XMPP servers to support push notifications to multiple client implementations, via multiple external or proprietary push services.</li>
<li>Allow clients to receive push notifications from multiple third-party XMPP servers.</li>
<li>Eliminate the need for clients to proxy a user's XMPP session in order to enable push notifications.</li>
<pclass='em'>Note: Any publish-subscribe use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>XEP-0060</cite>. The reader is referred to <cite>XEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.</p>
<section1topic='Concepts and Approach'anchor='concepts'>
<p>XMPP Push works between the user's XMPP server and two push notification services in tandem:</p>
<ol>
<li>The user's XMPP server publishes notifications to the XMPP Push Service of each of the user's client applications.</li>
<li>The XMPP Push Service (as defined here) for a client application then delivers the notification to a third-party notification delivery service.</li>
<li>The third-party (and potentially proprietary or platform-dependent) push service delivers the notification from the client application's backend service to the user's device.</li>
<p>This two-tiered push architecture allows the user's XMPP server to deliver notifications to arbitrary third-party clients, and in turn allows those clients to use the appropriate delivery mechanism for their platforms without having to share any private keys or other credentials with the XMPP server.</p>
<section2topic='General Architecture of a Push Notification Service'anchor='general-architecture'>
<p>The current state-of-the-art for a generic push notification service requires four actors:</p>
<dl>
<di>
<dt>App Client</dt>
<dd>The app client is the software installed and ran by the user, and is the final receiver of a push notification.</dd>
</di>
<di>
<dt>App Server</dt>
<dd>The app server is a backend service for the app client. At minimum, the app server exists to trigger push notifications, but it often also performs business logic for the app.</dd>
</di>
<di>
<dt>User Agent</dt>
<dd>The user agent is a service running locally on the user's device which receives push notifications and delivers them to the appropriate application.</dd>
<dd>The push service ferries notifications from the App Server to the User Agent. How it does so is often proprietary and vendor/platform dependent.</dd>
<p>An XMPP Push Service is a PubSub service as defined by the XMPP <cite>XEP-0060</cite> extension. The functional difference between a Push Service and a generic pubsub service is that a Push Service will generally summarize and forward published content via non-XMPP mechanisms.</p>
<pclass='em'>Note: a Push Service is provided by a specific client application as part of the App Server. A user's XMPP server will typically <em>not</em> act as a Push Service itself, but will instead publish to the Push Services for the user's client applications.</p>
<section2topic='Recommended Defaults'>
<p>A Push Service MUST:</p>
<ul>
<li>Support the 'whitelist' access model and set it to the default.</li>
<li>Support the 'publish-only' affiliation.</li>
</ul>
</section2>
<section2topic='Business Rules'>
<p>Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user.</p>
<p>In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the server JID and the user's bare JID) to publish to the node to trigger notifications.</p>
<p>Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from server JIDs and bare user JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see <linkurl='#publish-options'>Enabling Notifications</link>).</p>
<p>Before enabling or disabling push services, a client SHOULD determine whether the user's server supports publishing push notifications; to do so, it MUST send a &xep0030; information quest to the user's bare JID:</p>
<examplecaption='Client queries server regarding protocol support'><