[jdev] polling MUC room properties

Peter Saint-Andre stpeter at jabber.org
Mon Apr 10 20:56:09 CDT 2006

Hash: SHA1

Peter Saint-Andre wrote:
> Robert McQueen wrote:
>>> I've double checked the spec, and tested on a server, but it seems that
>>> when the room owner reconfigures a room, nothing is sent to the current
>>> members of the room to explain that eg they can't talk any more if the
>>> room is made moderated, or won't be able to rejoin if it's made invite
>>> only, and aren't told the password if one is set. Is this right? If we
>>> consider how some IRC clients always displays these settings, are we
>>> expected to periodically disco the room to keep these displays fresh?
> The room can send a message with a status code of 104 when the room
> configuration changes, but that is not really called out in the JEP.
> I'll work that into the next version. See also:
> http://www.jabber.org/jeps/jep-0045.html#statuscodes
> Because there are many possible configuration changes, using a generic
> 104 status code may be preferable to defining one status code per event
> type (change from hidden to public, change from members-only to open,
> change from moderated to unmoderated, etc.). I am open to one status
> code per event, but I need to look into it further (e.g., what is sent
> if more than one change is made?).

I've added some status codes, service discovery recommendations (MUST
for now, perhaps to be changed to SHOULD), and security considerations
related to this issue. I'll post version 1.21pre2 here in a minute.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20060410/de6c2e9a/attachment-0002.bin>

More information about the JDev mailing list