[Standards] [XEP-0114 / XEP-0225] What error to use when component unavailable?

Dave Cridland dave at cridland.net
Sun Apr 12 22:06:05 UTC 2020

On Sun, 12 Apr 2020 at 14:13, Jonas Schäfer <jonas at wielicki.name> wrote:

> On Samstag, 11. April 2020 17:07:20 CEST Kim Alvefur wrote:
> > Hi,
> >
> > Some time ago I tried to join an IRC channel via a gateway, but the
> > client said that the room had too many users in it. Confused, I dug into
> > logs to see what was going on and it turned out that the gateway was
> > down and the XMPP server bounced any stanza sent to it with an error of
> > type=wait, service-unavailable. So, a generic "can't do that right now,
> > try again later". Makes sense.
> >
> > Investigating further, I found this in XEP-0045:
> >
> > https://xmpp.org/extensions/xep-0045.html#enter-maxusers
> >
> > So, in MUC, wait/service-unavailable means "too many users". Why isn't
> > this using resource-constraint?
> >
> > And what error should an XMPP server return if an external component is
> > disconnected? Neither XEP-0114 or 0225 seems to have anything to say
> > about this.
> Since this is a link between two server-like entities, I’d suggest to use
> remote-server-timeout with type='wait'.
> To a user/client, there is no difference for a remote entity being a
> dedicated
> server or a component. Using s2s-like errors for disconnected components
> seems
> just reasonable to me.
You can't, because although '114 is *like* an S2S session, it's like
connecting to a remote server fine and then the remote server saying
"Actually, I can't do that after all".

So you could try a host-unknown, but that means the host server for the
component has to check the availability of the component on connect - and
if the component drops later, when the S2S is established, that's awkward -
unless we just destroy the stream with a stream error at that point. Fine
if you're not pipelining of course.

I'd like to see a solution to this, because it affects Metre, M-Link Edge,
and anything else doing true S2S proxying as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200412/4b6280f5/attachment.html>

More information about the Standards mailing list