From 64b62599a893057a02b8cdad6387af773b26c003 Mon Sep 17 00:00:00 2001 From: mathieui Date: Tue, 9 Feb 2021 16:12:58 +0100 Subject: [PATCH] XEP-0455: initial update after acceptance - 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 --- xep-0455.xml | 116 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 72 insertions(+), 44 deletions(-) diff --git a/xep-0455.xml b/xep-0455.xml index 9f111308..86498ac1 100644 --- a/xep-0455.xml +++ b/xep-0455.xml @@ -7,7 +7,8 @@
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. + This document defines an XMPP protocol extension that enables server administrators + to communicate issues with the server to all users in a semantic manner. &LEGALNOTICE; 0455 Experimental @@ -29,6 +30,12 @@ mathieui@mathieui.net mathieui@mathieui.net + + 0.2.0 + 2021-02-09 + + Evolve the standard: Editorial restructuring, add business rules and security considerations and clarify some wording. + 0.1.0 2021-02-09 @@ -54,11 +61,12 @@
  • A way to reference and archive such incidents, in a &xep0060; node
    • - -

    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.

    + + +

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

    - 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 + urn:xmpp:sos:0 http://secondary.shakespeare.lit/status.json @@ -87,15 +95,15 @@ ]]> -

    Links present inside the 'external-status-addresses' field SHOULD use HTTP/HTTPS protocol and the resources referenced MUST be available without authentication.

    +

    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.

    - + +

    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.

    + +

    When the outage is over, the file SHOULD be replaced with an empty JSON object.

    + + -

    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:

    -

    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 with this extension SHOULD expose a 'urn:xmpp:sos:0' + pubsub node with the acess model defined in &xep0222; on its bare JID. + This pubsub node contains items describing outages and outage resolutions, and each item MUST have an 'id' attribute value containing + the outage date and 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 external services + to monitor the server. Doing so allows aggregation of XMPP outage events across the network, for a better + transparency.

    +     + -

    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 @@ -188,15 +206,15 @@ ]]> - - + - + The ICQ and MSN gateways are down Les passerelles ICQ et MSN sont mortes false @@ -208,6 +226,9 @@ ]]> +     + +

    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.

    @@ -215,9 +236,9 @@ - + - + Everything has been fixed! Tout a été corrigé ! @@ -229,7 +250,7 @@

    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:

    @@ -241,13 +262,20 @@

    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

    + for later use. Doing so allows the client to use this information when it is impossible to connect + to the server.

    +

    A client receiving 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.

    +

    When connected, a client SHOULD NOT fetch the external file as the in-band notification provides + the same information, if available.

    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.

    +

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

    @@ -255,10 +283,10 @@

    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.

    +

    &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:sos:0" FORM_TYPE.

    - urn:xmpp:tmp:sos + urn:xmpp:sos:0 XEP-XXXXX Form enabling a the registration of a machine-readable