diff --git a/inbox/service-outage-status.xml b/inbox/service-outage-status.xml new file mode 100644 index 00000000..2112a45b --- /dev/null +++ b/inbox/service-outage-status.xml @@ -0,0 +1,272 @@ + + +%ents; +]> + + +
+ Service Outage Status + This document defines an XMPP protocol extension that enables a server to communicate issues with the server to all users in a semantic manner. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0060 + XEP-0128 + XEP-0222 + + + + NOT_YET_ASSIGNED + + Mathieu + Pasquet + mathieui@mathieui.net + mathieui@mathieui.net + + + 0.0.1 + 2021-01-18 + mp +

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;.

+ + + +]]> + + + + + + + + urn:xmpp:tmp:sos + + + http://secondary.shakespeare.lit/status.json + + + + +]]> + +

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.

+ + + + + + + The ICQ and MSN gateways are down + Les passerelles ICQ et MSN sont mortes + false + 2021-01-01T05:00:00Z + + + + + +]]> + + + + + + + The ICQ and MSN gateways are down + Les passerelles ICQ et MSN sont mortes + false + 2021-01-01T05:00:00Z + + + + + +]]> + +

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.

+ + + + + + + Everything has been fixed! + Tout a été corrigé ! + + + + + +]]> + +

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.

+
+