[Standards] Removal of GC1.0 from MUC / XEP-0045
dave at cridland.net
Tue Apr 10 10:32:19 UTC 2018
Thanks very much for doing this work.
Without meaning to imply whether or not I agree with your conclusions, a
couple of points of order:
1) While the Council can vote on the general principle, this has only the
effect of a statement of principle or intent. As Chair, I'm happy to do
this, I just note the results might not be what you want.
2) Such a vote has no relevance to the disposition of the PR you propose.
Even if the Council votes *not* to deprecate GC 1.0 abent a PR, a specific
PR can still be written and any such PR must be voted upon whether vote (1)
passes or not.
On 10 April 2018 at 09:29, Georg Lukas <georg at op-co.de> wrote:
> It is this time of the month again. Georg is trying to fix MUC.
> This time, I'm asking the Council to remove GC1.0 support from XEP-0045.
> In case this motion is approved, I'd prepare a PR against 0045 where the
> respective section will be replaced by a stub, and where servers will be
> advised to respond to join-less presence with either <not-acceptable/>
> or a <status code='307'/> presence (I think the former is more elegant).
> The last time this was brought up, concerns were raised that we do not
> know how many clients / users still rely on this behavior. Therefore,
> Kim kindly created https://modules.prosody.im/mod_muc_gc10.html which
> logs GC1.0 joins and asks the joining client for their version.
> I've been running this module on yax.im for the last two weeks, and
> ngathered additional feedback from other server operators. Almost all of
> the GC1.0 joins were traced back to clients that _do_ support proper MUC
> joins, and therefore are symptoms of c2s/s2s desynchronizations.
> The two instances of GC1.0 joins that most probably are actual GC1.0
> joins are:
> * the prosody webchat client (unmaintained, semi-abandoned, but I have
> an idea who's the non-maintainer and maybe they'd fix it if we ask
> very nicely)
> * Sawim for Android which I tested myself and failed to join any MUCs
> beacuse of its awesome UI. But it makes it easy to add a MUC as a
> roster item, obviously leading to user confusion and GC1.0-induced
> failure. So I ended up reverse engineering the APK, which indeed
> seemed to support the proper MUC protocol.
> Because of this obvious lack of GC1.0 usage in the field, the fact that
> adding a MUC to your roster will induce GC1.0 behavior that most
> probably won't be comprehended by clients, and the desync problems of
> GC1.0 that I outlined in  and at the Summit, I motion for permanent
> deactivation of GC1.0 support.
> Kind regards,
>  https://mail.jabber.org/pipermail/standards/2017-October/033501.html
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards