[Standards] MUC and data forms

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Nov 19 16:04:17 UTC 2009


I've put some proposed clarifications online:
http://git.collabora.co.uk/?p=user/smcv/xmpp.git;a=shortlog;h=refs/heads/muc-data-forms

On Wed, 18 Nov 2009 at 15:36:52 -0700, Peter Saint-Andre wrote:
> On 11/17/09 5:11 AM, Simon McVittie wrote:
> > 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).

It looks as though you're agreeing with the Openfire/Tigase/ejabberd
interpretation here, I think, since users with affiliation >= owner default
to gaining moderator role whenever they join, and can gain moderator role
whenever they want to.

By "any participant" I assume you mean "anyone with role >= participant",
which is Openfire/etc.'s interpretation. Would you accept a patch for XEP-0045
that recommended that interpretation?

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

By "in the disco#info" I mean when querying for room information on a
specific room, as the user SHOULD do before joining (XEP-0045 §6.3), not
as something searchable-for. Yes, it would be possible to list all rooms
and disco them all (n+1 round trips for n rooms), but a user contemplating
joining rooms and spamming the subject could equally well join those rooms
and spam the content (with messages), and will likely get banned either
way :-)

Some context: when we join a room, our XMPP implementation (telepathy-gabble)
wants to tell the API user whether they can change the subject. We can't
query the roomconfig because we're probably not an admin, but we can easily
check the disco#info.

> > 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'>
>         <value>xmpp:pubsub.shakespeare.lit?;node=the-darkcave-node</value>
>       </field>
> 
> Whether anyone uses that is another question...

I can understand the purpose; my point was that the version with *roominfo*
in the name only exists in an example and not in the registry submission,
whereas the version with *roomconfig* is in the normative specification.
If nobody actually implements this yet anyway, I'd prefer to limit the
duplication between roominfo and roomconfig.

Regards,
    Simon
-------------- 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/20091119/e90ffc7f/attachment.sig>


More information about the Standards mailing list