[Standards] MUC and data forms
stpeter at stpeter.im
Fri Nov 20 15:08:23 UTC 2009
On 11/19/09 9:04 AM, Simon McVittie wrote:
> I've put some proposed clarifications online:
> 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?
I agree with that interpretation. Patches are always welcome. :)
>>> 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.
Yes, that makes sense. And I assume you do that so you can show
appropriate features in the user interface?
>>> 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
>> That's for an associated pubsub node:
>> <field var='muc#roominfo_pubsub' label='Associated pubsub node'>
>> 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.
I don't see great harm in duplicates (it's the same information in
different contexts), but we need to make it clearer in the text and the
registries that some of this data is configuration-driven (e.g., the
pubsub node associated with the room) and other data is more dynamic
(e.g., number of occupants).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards