[Standards] MUC and data forms (was: MUC, MUC, glorious MUC)

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Nov 17 12:11:32 UTC 2009

Various data-forms-related things from XEP-0045 that I'd like to see clarified,
while on the subject of MUCs:


I've recently been trying to implement a check for muc#roomconfig_changesubject 
in telepathy-gabble, so we can close a long-standing bug (when Telepathy UIs
ask an XMPP MUC whether they can change the subject, we can't give a
meaningful answer).

However, the spec for this parameter in XEP-0045 seems rather vague. Having
consulted the code of some open-source implementations:

* in Openfire, Tigase and ejabberd, muc#roomconfig_changesubject = false
  means that role == moderator can change the subject, while true means that
  role >= participant (i.e. participants and moderators) can change the subject

* in mu-conference, false means that affiliation >= admin (i.e. admins and
  owners) can change the subject, while true means that anyone in the room
  (role >= visitor) can change the subject

* in Prosody, anyone in the room can change the subject

One possible solution would be to deprecate muc#roomconfig_changesubject as
being too vague, and either define a new field muc#roomconfig_subjectrole of
type list-single, which is the minimum role to set the subject, or follow
muc#roomconfig_getmemberlist by defining a new field of type list-multi
containing roles and affiliations which can change the subject (I think the
latter would be overkill).

An alternative solution would be to declare that one of the implementations
is right and the other is wrong. I'd be inclined to say that the interpretation
used in Openfire, Tigase and ejabberd seems appropriate.


XEP-0045 suggests that muc#roomconfig_changesubject could (should?) be in the
room's disco#info. According to my tests on various public servers, nobody
actually does that yet, but including selected roomconfig_ fields in the
disco#info seems a good approach for the future.

Example 8 "Room Returns Extended Disco Info Results" of XEP-0045 contains
both muc#roominfo_changesubject and muc#roomconfig_changesubject, with
different labels ("Whether Occupants May Change the Subject" and "Subject
can be modified" respectively). muc#roominfo_changesubject is not included
in the muc#roominfo FORM_TYPE registry submission, and I haven't found an
implementation of it; I suggest deleting the reference to this field altogether.

The muc#roominfo FORM_TYPE registry submission does include
muc#roominfo_subjectmod, labelled "The room subject can be modified by
participants". I haven't found an implementation of this either, and I suggest
deleting it. Its label could be treated as evidence in favour of
using participant as the threshold role for subject modification with
muc#roominfo_changesubject, i.e. agreeing with Openfire, Tigase and ejabberd;
however, it seems almost equally likely that "participant" is used here in
its non-jargon sense.


The muc#roominfo FORM_TYPE registry submission does not appear in
<http://xmpp.org/registrar/formtypes.html>, presumably a registry oversight?

In the muc#register FORM_TYPE, the registry submission mentions
muc#register_allow, but that registry page does not.

muc#roomconfig_getmemberlist and muc#roomconfig_pubsub do not appear in that
registry page either.

The muc#register FORM_TYPE registry defines muc#register_first and
muc#register_last to be first name and last name, but the XEP defines
them to be given name and family name. I propose that these be changed to
given name and family name consistently, in the same way that XEP-0055 Contact
Search was clarified in version 1.3.


Example 8 "Room Returns Extended Disco Info Results" contains
muc#roominfo_pubsub, which does not appear in the roominfo registry submission.
I haven't checked whether any implementations support this field, but I
suspect that it's a typo for muc#roomconfig_pubsub; I propose amending the


Some other clarifications which I think would be worthwhile (I haven't checked
whether these are actually true in XMPP server implementations, though):

* What muc#roomconfig_allowinvites = true means by "Allow Occupants..." -
  either "allow roles >= visitor to invite others" or "allow roles >=
  participant to invite others", presumably, whereas
  muc#roomconfig_allowinvites = false means "allow only moderators to invite

* muc#roominfo_description and muc#roomconfig_roomdesc are the same attribute,
  so disco#info SHOULD NOT include muc#roomconfig_roomdesc, and changing
  muc#roomconfig_roomdesc SHOULD change muc#roominfo_description.

* Similarly, muc#roominfo_lang and muc#roomconfig_lang are the same attribute.

* muc_nonanonymous and muc_semianonymous are mutually exclusive; if neither
  feature is present, the room is anonymous.

* muc_open and muc_membersonly are opposites; each room should have exactly
  one of these features. muc#roomconfig_membersonly selects which one is

* Similarly, muc_unmoderated and muc_moderated are opposites.
  muc#roomconfig_moderatedroom selects which one is active.

* Similarly, muc_temporary and muc_persistent are opposites.
  muc#roomconfig_persistentroom selects which one is active.

* Similarly, muc_public and muc_hidden are opposites.
  muc#roomconfig_publicroom selects which one is active.

* Similarly, muc_passwordprotected and muc_unsecured are opposites.
  muc#roomconfig_passwordprotectedroom selects which one is active. In
  particular, muc_unsecured has nothing to do with TLS/SSL.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20091117/483f744e/attachment.sig>

More information about the Standards mailing list