- Address the issue of the tmp namespace
- Fixup abstract
- Restructure to use subsections
- Clarify usage of future date times
- Clarify the pubsub node a bit further
- Add some business rules & security considerations
<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>
<abstract>This document defines an XMPP protocol extension that enables server administrators
to communicate issues with the server to all users in a semantic manner.</abstract>
&LEGALNOTICE;
<number>0455</number>
<status>Experimental</status>
@ -29,6 +30,12 @@
@@ -29,6 +30,12 @@
<email>mathieui@mathieui.net</email>
<jid>mathieui@mathieui.net</jid>
</author>
<revision>
<version>0.2.0</version>
<date>2021-02-09</date>
<initials></initials>
<remark>Evolve the standard: Editorial restructuring, add business rules and security considerations and clarify some wording.</remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2021-02-09</date>
@ -54,11 +61,12 @@
@@ -54,11 +61,12 @@
<li>A way to reference and archive such incidents, in a &xep0060; node</li>
<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 <linkurl='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
<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:sos:0" (as already specified in <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <linkurl='#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>
<examplecaption='Entity queries server for information'><![CDATA[
<p>Values of 'external-status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of &w3xmlschema2;.</p>
<examplecaption='Entity queries server for information'><![CDATA[
<p>Links present inside the 'external-status-addresses' field SHOULD use HTTP/HTTPS protocol and the resources referenced MUST be available without authentication.</p>
<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>
<section1topic='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>
<examplecaption='Example status'><![CDATA[
</section2>
<section2topic='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>
<examplecaption='Example status'><![CDATA[
{
"outage": "complete",
"planned": true,
@ -106,17 +114,23 @@
@@ -106,17 +114,23 @@
"en": "The serveur is being updated"
}
}
]]></example>
]]></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>When the outage is over, the file SHOULD be replaced with an empty JSON object.</p>
<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>
<examplecaption='Empty file after resolution of the issue'><![CDATA[
{}
]]></example>
<p>The following JSON schema is provided as a means to describe and validate the
file exposed by the external service:</p>
<p>The following JSON schema is provided as a means to describe and validate the
<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>
<p>Client implementations MUST check the provenance of the pubsub notifications before displaying a notification, otherwise malicious entities could send fake outage events.</p>
<p>Server administrators MUST ensure the servers provided in 'external-status-addresses' are trusted, as malicious administrators of this server could use the referenced file
<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>
<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:sos:0" FORM_TYPE.</p>
<codecaption='Registry Submission'><
mathieui
2 years ago
committed by