[Standards] MUC and data forms

Peter Saint-Andre stpeter at stpeter.im
Wed Nov 18 22:36:52 UTC 2009

On 11/17/09 5:11 AM, Simon McVittie wrote:
> 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.

The intent behind changesubject is to either allow any participant to
change the subject, or to lock it down to anyone above participant level
(which typically means moderator or above in a moderated room or admin
in an unmoderated room).

But subjectroles (or somesuch) would be fine with me -- e.g., owner and
admin can change subject, but moderator can't. The sensible values would
be "owner", "admin+", "moderator+", "member+", "anyone" (or whatever).

> ------------------
> 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.

Hmm, this might open up attacks ("disco for rooms that allow anyone to
change the subject so that I can cause trouble there").

> 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.

In fact it's used in the jargony sense. But I agree that we have some
overlap here, perhaps some residual copy-and-paste problems.

> ------------------
> 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.

That field is used here:


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

More registry oversights.

> 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.

I updated XEP-0045 about that, IIRC, but perhaps didn't regenerate
XEP-0045 on the website.

> ------------------
> 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
> example.

That's for an associated pubsub node:

      <field var='muc#roominfo_pubsub' label='Associated pubsub node'>

Whether anyone uses that is another question...

> ------------------
> 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
>   others"?

Correct. I think it would never apply to visitors.

> * 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.

Right -- roomconfig to roominfo is a one-way street.

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

Yes. Same information, different contexts.

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

But nothing supports true anonymity, AFAIK. So it needs to be either non
or semi (at least in current implementations).

> * muc_open and muc_membersonly are opposites; each room should have exactly
>   one of these features. muc#roomconfig_membersonly selects which one is
>   active.
> * 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.



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20091118/189767da/attachment.bin>

More information about the Standards mailing list