The XMPP Network is a network of servers which each have their own administration policies, status reports, and other peculiarities. &xep0157; provides a consistent framework for reaching out to administrators and reporting abuse, incidents, or even giving feedback on the service, and the goal of this specification is to provide a similar framework for letting users (or other entities) know the server status in-band or out of band (in case of hard failures).

Centralized systems usually control both the infrastructure and client code, making it easy to hardcode information retrieval one way or the other.

The usual way of informing users of planned maintenance, partial or total outage was previously through "announce" modules that lets the admin broadcast server-wided messages. This approach has several drawbacks, as it will appear in most clients as a new discussion with the server JID, which can prove confusing. It also does not provide a way to reach the user when the XMPP server is offline.

This XEP provides:

• An informational way of exposing an external service endpoint containing machine-readable data using &xep0128;
• A specification of the data this service should provide
• A normative way of providing such information in-band, when the outage is not complete
• A way to reference and archive such incidents, in a &xep0060; node

To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "urn:xmpp:tmp:sos" (as already specified in XEP-0128) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

Values of 'external-status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of &w3xmlschema2;.

Links present inside the 'external-status-addresses' field SHOULD use HTTP/HTTPS protocol and the resources referenced MUST be available without authentication.

TODO: do we want this to be XML or json? I have no real preference, in any case it should be preferably generated by a tool but easy to write by hand, as this needs to be usable in situations where time is the essence.

The format used for the external status is defined here, to allow a wide range of compatibility across services and clients.

A client MUST ignore unknown extra fields present in the JSON file, to allow extensibility, and implementations MAY add other fields.

The "message" field MUST contain at least a message on the "default" key, that will be used by the client if the current user language is not found. It is left to the operator to determine which language is more relevant as a default, according to the server’s user base.

The following JSON schema is provided as a means to describe and validate the file exposed by the external service:

For in-band notifications of server issues, a service MUST expose a pubsub node with the acess model defined in &xep0222;. This pubsub node contains items describing outages, and each item MUST have an 'id' attribute value containing the publishing time, in &xep0082; format.

Clients implementing this extension SHOULD subscribe to the '+notify' on that node, as defined in &xep0060;.

Entities from other servers MAY be allowed to subscribe to other server nodes, to allow an external service to monitor the server. Doing so allows aggregation of XMPP outage events across the network, for a better transparency.

When the outage is over, servers operators SHOULD publish an <outage-end/> element with the item id matching the time at which the issue was resolved. It can optionally contain a description.

Clients receiving this notification SHOULD remove the information about the outage from the user’s view, and MAY display the new message briefly.

This extension has been thought for several different cases of service outages:

• A client failing to connect to a server is able to display an informative message to the user if the server is having issues.
• A server experiencing difficulties is able to communicate it to the users, and clients can display the information prominently.
• An external service can keep track of the various outages, either for a single server or a number of them, and present the information in a structured manner.

A client implementing this extension MUST fetch the addresses of the external service and cache it for a reasonable amount of time (several days), to be able to use it when an issue occurs

Both the JSON and the XML format defined in this document allow for internationalization in the fields that are expected to be presented to the user as-is. The other fields are machine-readable and their various values SHOULD be translated in the implementing applications.

Client implementations MUST check the provenance of the pubsub notifications before displaying a notification, otherwise malicious entities could send fake outage events.

This document requires no interaction with &IANA;.

The ®ISTRAR; includes the following information in its registries.

REQUIRED for protocol specifications.