First draft.
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:
+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 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.
+&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "urn:xmpp:tmp:sos" FORM_TYPE.
+
+ urn:xmpp:tmp:sos
+ XEP-XXXXX
+
+ Form enabling a the registration of a machine-readable
+ external file to describe a service status.
+
+
+ REQUIRED for protocol specifications.
+