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
signature.asc
Description: Digital signature
