[Standards] Proposed XMPP Extension: Service Outage Status

Mathieu Pasquet mathieui at mathieui.net
Wed Jan 20 17:29:27 UTC 2021


On 20.01.2021 15:55, Jonas Schäfer wrote:
>The XMPP Extensions Editor has received a proposal for a new XEP.
>
>Title: Service Outage Status
>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.
>
>URL: https://xmpp.org/extensions/inbox/service-outage-status.html
>
>The Council will decide in the next two weeks whether to accept this
>proposal as an official XEP.
>_______________________________________________
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: Standards-unsubscribe at xmpp.org
>_______________________________________________

Some notes on the choices made here in the hope to get more feedback
from server and client authors:

We need an external source of information which does not rely on
an XMPP connection, to be able to convey information when the
  server is down.

0128 is already used widely, in 0157 or 0363 and therefore
supported in both servers and clients. Moreover, clients
will usually disco their server first thing on connect,
which means there is no need to handle expiration of the link
to the external source explicitly.

Pubsub was chosen as the in-band notification mechanism because
it allows notifications to the supporting clients whithout
the need to define anything else. I am not a pubsub expert,
but it looks like most modern clients already have a PEP
implementation one way of the other (e.g. for bookmarks), and
the "user" side of this XEP does not require features that
are outside of 0163.
As far as I am aware, the publisher side is not PEP only because
server admins push events to the JID, requiring a different
publishing model.

Not being a server developer, I do not know how hard it could
be to expose a pubsub service on the domain’s bare JID. I
imagine some implementation-specific constraints could make it
really hard. If that is the case, please do tell, so we can
figure out a better way (like putting a jid in the disco form
which clients should subscribe to instead)!


Best regards,
Mathieu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20210120/6e6530ec/attachment-0001.sig>


More information about the Standards mailing list