The XMPP Network is a network of servers which each have their own administration policies, status reports, and other peculiarities. Contact Addresses for XMPP Services (XEP-0157)XEP-0157: Contact Addresses for XMPP Services <https://xmpp.org/extensions/xep-0157.html>. 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 Service Discovery Extensions (XEP-0128)XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>.
A specification of the data this service should provide
A normative way of providing such information in-band, when the outage is not complete
To make such discovery possible, we specify a Service Discovery Extensions (XEP-0128)XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>. 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:sos:0" (as already specified in Service Discovery Extensions (XEP-0128)XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>.) 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 XML Schema Part 2XML Schema Part 2: Datatypes <http://www.w3.org/TR/xmlschema11-2/>..
Links present inside the 'external-status-addresses' field SHOULD use HTTP/HTTPS protocol and the resources referenced MUST be available without authentication.
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, when set, MUST contain at least a message on the "default" key
which will be used by clients 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.
When the outage is over, the file SHOULD be replaced with an empty JSON object.
The following JSON schema is provided as a means to describe and validate the
file exposed by the external service:
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 later use. Doing so allows the client to use this information when it is impossible to connect
to the server.
A client fetching an outage event for a time in the future SHOULD treat it as a planned event
that is not already happening and adapt its display consequently.
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.
Clients MUST display the message in a way that makes it as readable as the rest of the application for visually impaired people, and the message text MUST likewise be available to screen readers.
Server administrators MUST ensure the servers provided in 'external-status-addresses' are trusted, as malicious administrators of this server could use the referenced file
to display arbitrary messages to users.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..
The XMPP RegistrarThe XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>. includes the following information in its registries.
Field Standardization for Data Forms (XEP-0068)XEP-0068: Field Data Standardization for Data Forms <https://xmpp.org/extensions/xep-0068.html>. defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and Service Discovery Extensions (XEP-0128)XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>. describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "urn:xmpp:sos:0" FORM_TYPE.
urn:xmpp:sos:0XEP-0455
Form enabling a the registration of a machine-readable
external file to describe a service status.
]]>
No XML Schema is required as this does not define new XML elements.