XEP-0045 muc#roomconfig_allowinvites in practise
Stephen Paul Weber <[email protected]>
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
Hello everyone, XEP-0045 is very quiet about how some of the options are to be interpreted. For muc#roomconfig_allowinvites there is only one normative line in the XEP, in the registry submission, which is "Whether to Allow Occupants to Invite Others" Now, it seems that ejabberd and Conversations have interpreted this to mean "whether to allow occupants *who wouldn't normally be able to invite otherwise* to invite other" which is to say, pretty much, in a members only room can members invite members. On means members invite members, off means only admin can (actually Conversations checks for moderator role not for admin...) This feels like the correct implementation to me given that you can't meaningfully restrict invitations to a pubilc MUC (you could block mediated invitations but we're moving away from those and they don't do anything special in a public MUC traditionally) and it seems like nonsense to ban admins from inviting members (since the admins can change this settings anyway?) Why it matters: currently Prosody does not implement this option at all, because it seemed from the descriptio to mean something nonsensical. So Prosody has (AFAICT) implemented the same thing as ejabberd and Conversations, but under a custom name to make it clear how it works. My proposal: change the one line of text in the XEP to instead read "Whether to Allow Members to Invite Others". _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEWeaCw+rzmiEMpzU00RwpEc5RnN4FAmknLSQACgkQ0RwpEc5R nN5JxA/+ODpW+gceDpms/LmRX530LhYSbDC6bhEVg+lMmMQd3p1HUp88vaK+ROck vhO2RTKYbryv/u7zq6HvgriLJlKux/JE0IJF0tug2bKlWCwvvfA/Vjvx3Eylipup W3WGM0w2ceQow5871UjdIa6bcIRLWC7MjoCDfyfPZDq18w1qM8qhzFyod0HcNmnN Hn4E6u93nUI7tQWrG9rslJCKwZH1G4bcufq0uTcGNWM43WL+i+T22Ye7VL9dlNl5 e0EMkzDtLPEJru4CMBdxDRUYdO7VUP3z8SBaJ2S43pHSnhpVPVXARSRtJjBxQIiC lhQN9neFbetDjKlgAlfrvI++3haask8pnNRYQWsVtf4V331wMLhf9eDBU3YbJD5Z p4y4pZ01fZc+mHuRAtsZTczrsL7gSgOqu1zflnLh/hjsccSbjwi/ViV3TREWRp61 thkItobgyjp3eY2Mt5J3jBZgPD80R2GVXFm3ujsnPtV+f2Uq+KGgZ/99yYBB4ymS KGnWNCJOsOe2ecuIR8a4bH+r6keKcG7TirMVXRBGLNupHZGuQN+UXvvtV70ECa82 4xGnpvtsMAHfxGaMtwXyR/9w46vVASFnd9+AtwywdFY179x6DOHeQfJDGDSLSvLw KUtghiDep7PHQFT+SlmMmYdt00EQ3mlataTYkKXaD62TXKL87NM= =ycqQ -----END PGP SIGNATURE-----