As promised, here are some questions and comments on the proposed MUC message moderation specs:
http://www.xmpp.org/extensions/inbox/msg_moderate.html http://www.xmpp.org/extensions/inbox/room_moderator.html 1. I think it makes sense to combine the two specs into one, with separate sections for the occupant and moderator use cases. 2. What is the rationale for sending out state changes via presence from the room's JID? http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state How will existing clients handle such state notifications? I think we need to come up with a generic approach here. Perhaps the authors of the message moderation proposal could collaborate with the authors of the MUCOL proposal (not yet submitted)? They use IQs, not presence. http://www.wimba.com/labs/mucol/ 3. Why is the message sender forced to flag the message as intended for moderation? http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state It seems to me that this forces the client to be smart about the state of the room. Older clients may not be that smart, and in any case I think the room (MUC service) can intelligently decide how to handle messages without forcing that intelligence on the sender. Also there is a dependency here for the client to include an 'id' attribute, which many clients do not. IMHO it would be good to enable the clients to be fairly dumb in order to participate in a message-moderated MUC. 4. If undeliverable messages are sent with type='groupchat' then I think older clients could get confused. http://www.xmpp.org/extensions/inbox/msg_moderate.html#message-moderation-result 5. Example 10 says it is an error but the type is groupchat. http://www.xmpp.org/extensions/inbox/msg_moderate.html#example-10 6. The cancellation workflow strikes me as similar to XEP-0142. Perhaps it would be good to make the two approaches consistent (or at least not very different). http://www.xmpp.org/extensions/inbox/msg_moderate.html#message-submission-cancel 7. We probably want a consistent protocol between XEP-0045 and moderator management to request privileges. http://www.xmpp.org/extensions/inbox/room_moderator.html#start-moderation http://www.xmpp.org/extensions/xep-0045.html#requestvoice 8. Use of the term "moderator" might provide confusion with XEP-0045, unless you're just adding a new privilege to the existing role. If this is a new role, then we need to think clearly about how we want to do that, since others might want new roles and affiliations too (e.g., for multi-user media conferences, whiteboarding, etc.). 9. I'm not sure what it means to "leave as a moderator" -- does that mean to stop being a moderator? Isn't that a simple role change per XEP-0045? 10. In order to moderate messages, why don't we use Data Forms as we do for voice requests? http://www.xmpp.org/extensions/inbox/room_moderator.html#message-moderation-submit http://www.xmpp.org/extensions/xep-0045.html#voiceapprove /psa
smime.p7s
Description: S/MIME Cryptographic Signature
