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. Dave. On 10 April 2018 at 09:29, Georg Lukas <ge...@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 [0] and at the Summit, I motion for permanent > deactivation of GC1.0 support. > > > Kind regards, > > Georg > > [0] https://mail.jabber.org/pipermail/standards/2017-October/033501.html > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
