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 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE xep SYSTEM 'xep.dtd' [
+  <!ENTITY % ents SYSTEM 'xep.ent'>
+%ents;
+]>
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
+<xep>
+<header>
+  <title>Service Outage Status</title>
+  <abstract>This document defines an XMPP protocol extension that enables a server to communicate issues with the server to all users in a semantic manner.</abstract>
+  &LEGALNOTICE;
+  <number>xxxx</number>
+  <status>ProtoXEP</status>
+  <type>Standards Track</type>
+  <sig>Standards</sig>
+  <approver>Council</approver>
+  <dependencies>
+    <spec>XMPP Core</spec>
+    <spec>XEP-0060</spec>
+    <spec>XEP-0128</spec>
+    <spec>XEP-0222</spec>
+  </dependencies>
+  <supersedes/>
+  <supersededby/>
+  <shortname>NOT_YET_ASSIGNED</shortname>
+  <author>
+    <firstname>Mathieu</firstname>
+    <surname>Pasquet</surname>
+    <email>mathieui@mathieui.net</email>
+    <jid>mathieui@mathieui.net</jid>
+  </author>
+  <revision>
+    <version>0.0.1</version>
+    <date>2021-01-18</date>
+    <initials>mp</initials>
+    <remark><p>First draft.</p></remark>
+  </revision>
+</header>
+<section1 topic='Introduction' anchor='intro'>
+  <p>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).</p>
+  <p>Centralized systems usually control both the infrastructure and client code, making it easy to hardcode information retrieval one way or the other.</p>
+  <p>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.</p>
+    <p>This XEP provides:</p>
+    <ul>
+        <li>An informational way of exposing an external service endpoint containing machine-readable data using &xep0128;</li>
+        <li>A specification of the data this service should provide</li>
+        <li>A normative way of providing such information in-band, when the outage is not complete</li>
+        <li>A way to reference and archive such incidents, in a &xep0060; node</li>
+    </ul>
+</section1>
+<section1 topic='External endpoint discovery' anchor='external-disco'>
+  <p>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 <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
+
+  <p>Values of 'external-status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of &w3xmlschema2;.</p>
+  <example caption='Entity queries server for information'><![CDATA[
+<iq from='thirdwitch@shakespeare.lit/chamber'
+    to='shakespeare.lit'
+    id='disco1'
+    type='get'>
+  <query xmlns='http://jabber.org/protocol/disco#info'/>
+</iq>
+]]></example>
+
+  <example caption='Server communicates information'><![CDATA[
+<iq from='shakespeare.lit'
+    to='thirdwitch@shakespeare.list/chamber'
+    id='disco1'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <identity category='server' type='im'/>
+    <feature var='http://jabber.org/protocol/disco'/>
+    <x xmlns='jabber:x:data' type='result'>
+      <field var='FORM_TYPE' type='hidden'>
+        <value>urn:xmpp:tmp:sos</value>
+      </field>
+      <field var='external-status-addresses'>
+        <value>http://secondary.shakespeare.lit/status.json</value>
+      </field>
+    </x>
+  </query>
+</iq>
+]]></example>
+
+  <p>Links present inside the 'external-status-addresses' field SHOULD use HTTP/HTTPS protocol and the resources referenced MUST be available without authentication.</p>
+
+</section1>
+<section1 topic='External status format' anchor='json-schema'>
+  <p>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.</p>
+  <p>The format used for the external status is defined here, to allow a wide range
+     of compatibility across services and clients.</p>
+  <p>A client MUST ignore unknown extra fields present in the JSON file, to allow extensibility, and implementations MAY add other fields.</p>
+  <example caption='Example status'><![CDATA[
+{
+  "outage": "complete",
+  "planned": true,
+  "beginning": "2021-01-12T01:01:01Z",
+  "expected_end": "2021-01-12T05:00:00Z",
+  "message": {
+    "default": "Mise à jour du serveur",
+    "en": "The serveur is being updated"
+  }
+}
+]]></example>
+
+  <p>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.</p>
+
+  <p>The following JSON schema is provided as a means to describe and validate the
+     file exposed by the external service:</p>
+
+  <code><![CDATA[
+{
+  "$id": "http://xmpp.org/server-outage-schema.json",
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "XMPP Server Outage Format",
+  "type": "object",
+  "required": ["beginning"],
+  "additionalProperties": true,
+  "properties": {
+    "outage": {
+      "type": "string",
+      "enum": ["partial", "complete"],
+      "description": "The outage status (partial or complete)."
+    },
+    "planned": {
+      "type": "boolean",
+      "description": "If the outage was planned or not."
+    },
+    "beginning": {
+      "type": "string",
+      "format": "date-time",
+      "description": "Approximate time of the start of the outage."
+    },
+    "expected_end": {
+      "type": "string",
+      "format": "date-time",
+      "description": "Estimated time of the end of the outage (if known)."
+    },
+    "message": {
+    "type": "object",
+      "description": "Textual message to service users, each key being 'defaul' or a BCP47 language tag.",
+      "required": ["default"],
+      "properties": {
+        "default": { "type": "string"}
+      },
+      "patternProperties": {
+        "default": {"type": "string"},
+        ".*": {"type": "string"}
+      }
+    }
+  }
+}
+]]></code>
+
+</section1>
+<section1 topic="Pubsub Node" anchor="pubsubnode">
+
+  <p>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.</p>
+  <p>Clients implementing this extension SHOULD subscribe to the '+notify' on that node, as defined in &xep0060;.</p>
+  <p>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.</p>
+
+  <example caption='Server operator publishes an outage event'><![CDATA[
+  <iq from='firstwitch@shakespeare.lit/broom' to='shakespeare.lit' type='set' id='pub1'>
+  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
+    <publish node='urn:xmpp:tmp:sos'>
+      <item id="2021-01-01T01:01:01Z">
+        <outage xmlns='urn:xmpp:tmp:sos'>
+          <description xml:lang='en'>The ICQ and MSN gateways are down</description>
+          <description xml:lang='fr'>Les passerelles ICQ et MSN sont mortes</description>
+          <planned>false</planned>
+          <expected_end>2021-01-01T05:00:00Z</expected_end>
+        </outage>
+      </item>
+    </publish>
+  </pubsub>
+</iq>
+]]></example>
+
+  <example caption='Client subscribed receives an outage event'><![CDATA[
+<message from='shakespeare.lit'
+         to='macbeth@shakespeare.lit/throne'
+         type='headline'
+         id='outagefoo'>
+  <event xmlns='http://jabber.org/protocol/pubsub#event'>
+    <items node='urn:xmpp:tmp:sos'>
+      <item id="2021-01-01T01:01:01Z">
+        <outage xmlns='urn:xmpp:tmp:sos'>
+          <description xml:lang='en'>The ICQ and MSN gateways are down</description>
+          <description xml:lang='fr'>Les passerelles ICQ et MSN sont mortes</description>
+          <planned>false</planned>
+          <expected_end>2021-01-01T05:00:00Z</expected_end>
+        </outage>
+      </item>
+    </items>
+  </event>
+</message>
+]]></example>
+
+  <p>When the outage is over, servers operators SHOULD publish an &lt;outage-end/&gt; element
+      with the item id matching the time at which the issue was resolved. It can optionally
+      contain a description.</p>
+
+  <example caption='Server operator publishes an end of outage event'><![CDATA[
+  <iq from='firstwitch@shakespeare.lit/broom' to='shakespeare.lit' type='set' id='pub2'>
+  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
+    <publish node='urn:xmpp:tmp:sos'>
+      <item id="2021-01-01T02:05:01Z">
+        <outage-end xmlns='urn:xmpp:tmp:sos'>
+          <description xml:lang="en">Everything has been fixed!</description>
+          <description xml:lang="fr">Tout a été corrigé !</description>
+        </outage-end>
+      </item>
+    </publish>
+  </pubsub>
+</iq>
+]]></example>
+
+  <p>Clients receiving this notification SHOULD remove the information about the outage from the user’s view, and MAY
+     display the new message briefly.</p>
+
+</section1>
+<section1 topic='Use Cases' anchor='usecases'>
+  <p>This extension has been thought for several different cases of service outages:</p>
+  <ul>
+    <li>A client failing to connect to a server is able to display an informative message to the user if the server is having issues.</li>
+    <li>A server experiencing difficulties is able to communicate it to the users, and clients can display the information prominently.</li>
+    <li>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.</li>
+  </ul>
+</section1>
+<section1 topic='Business Rules' anchor='rules'>
+  <p>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</p>
+</section1>
+<section1 topic='Internationalization Considerations' anchor='i18n'>
+  <p>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.</p>
+</section1>
+<section1 topic='Security Considerations' anchor='security'>
+  <p>Client implementations MUST check the provenance of the pubsub notifications before displaying a notification, otherwise malicious entities could send fake outage events.</p>
+</section1>
+<section1 topic='IANA Considerations' anchor='iana'>
+  <p>This document requires no interaction with &IANA;.</p>
+</section1>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <p>The &REGISTRAR; includes the following information in its registries.</p>
+  <section2 topic='Field Standardization' anchor='registrar-formtype'>
+    <p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and <cite>XEP-0128</cite> 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.</p>
+    <code caption='Registry Submission'><![CDATA[
+<form_type>
+  <name>urn:xmpp:tmp:sos</name>
+  <doc>XEP-XXXXX</doc>
+  <desc>
+    Form enabling a the registration of a machine-readable
+    external file to describe a service status.
+  </desc>
+  <field
+      var='external-status-addresses'
+      type='list-multi'
+      label='One or more addresses containing a file with the server status'/>
+</form_type>
+]]></code>
+  </section2>
+</section1>
+<section1 topic='XML Schema' anchor='schema'>
+  <p>REQUIRED for protocol specifications.</p>
+</section1>
+</xep>