XEP-xxxx: Message Moderated Conferences

This XEP defines a way to submit messages for MUC moderation.

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2007-05-22
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0045
Supersedes: None
Superseded By: None
Short Name: Not yet assigned

Author Information

Mridul Muralidharan

Email: mridul@sun.com
JabberID: mm132998@sun.com

Rahul Shah

Email: rahul.shah@sun.com
JabberID: rs129080@sun.com

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents


1. Introduction
2. Requirements
3. Use Cases
    3.1. Recipients
    3.2. Discovering support for message moderation
    3.3. Message Moderation state
    3.4. User submitting a message for moderation
    3.5. Room managing messages
    3.6. Submitter cancelling message
4. Security Considerations
5. IANA Considerations
6. Jabber Registrar Considerations
    6.1. Protocol Namespaces
    6.2. Service Discovery Features
7. XML Schema
    7.1. http://jabber.org/protocol/muc#msg_moderate
8. Acknowledgements
Notes
Revision History

1. Introduction

This document defines a means for occupants without voice to submit multi-user chat messages for moderation and how the room manages them. XEP 0045 describes a way for a occupants to request for ability to post messages (request for voice). But in a lot of usecases, in particular for moderated public conferences, it will not be possible to give voice to all occupants wishing to speak. The messages being posted would need to be moderated by the room, which would then approve or reject the message. This proposal allows for this usecase and is an extension to XEP-0045

As of now, this protocol is envisioned to be used only with the MUC spec, not the older Groupchat 1.0.

2. Requirements

All the requirements mentioned in XEP-0045 are applicable. In addition,

  1. Allow a way for occupants with no voice to post approved messages to the room.
  2. MUST use access control mechanisms already defined in MUC.

3. Use Cases

Before getting into the specific usecases, we will define who should be the recipients of the message exchanges defined in this proposal.

3.1 Recipients

There are two types of broadcast's which could happen as a result of this XEP.
  1. Broadcast of approved message.
  2. Start and stop of message moderation.
Approved messages are to be handled as if the sender had voice in the room. The messages SHOULD not be distinguishable from messages posted by occupants who have voice.

Message moderation start and stop MUST be delivered to the following occupants and SHOULD NOT be delivered to others.

  1. Occupants with affiliations of moderator or owner.
  2. Occupants without a voice in the room.
The following MUST be delivered to the above mentioned recipients.
  1. Message moderation state change MUST be broadcasted.
  2. If message moderation is enabled, it MUST be delivered to any new occupant joining the room.
In addition to these, we also have the following recipients.
  1. If message moderation is enabled, it MUST be delivered to any occupant who loses his voice.
  2. If message moderation is enabled, a message moderation 'stop' notification MUST be delivered to any occupant who gains his voice (unless the occupants has an affiliations of moderator or owner).
Note that, the above MUST be sent irrespective of muc#presencebroadcast configuration.

3.2 Discovering support for message moderation

An entity wanting to discover if message moderation is supported for a room would send a disco#info query.

Example 1. User queries for support of message moderation

<iq from='crone1@shakespeare.lit/desktop'
    id='disco1'
    to='darkcave@macbeth.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

If the room supports message moderation, it MUST return the feature 'muc_moderated' (as per MUC) and 'http://jabber.org/protocol/muc#msg_moderate' (for this spec).

Example 2. MUC response to User query for support of message moderation

<iq from='darkcave@macbeth.shakespeare.lit'
    id='disco1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='text'/>
    ...
    <feature var='muc_moderated'/>
    ...
    <feature var='http://jabber.org/protocol/muc#msg_moderate'/>
    ...
  </query></iq>

3.3 Message Moderation state

As defined in Recipients, room MUST send start and stop of message moderation to room occupants.

Example 3. Notifying occupants when message moderation is started

<!-- Owner -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'>
  <action type='start' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>

<!-- Moderator -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <action type='start' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>

<!-- No voice -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'>
  <action type='start' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>

Example 4. Notification to occupants when message moderation is stopped

<!-- Owner -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <action type='stop' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>
        
<!-- Moderator -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'>
  <action type='stop' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>

<!-- No voice -->
<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'>
  <action type='stop' xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</presence>

3.4 User submitting a message for moderation

Only room occupants without voice MAY send a message for moderation. Messages from others MUST result in an error being returned.

The message submitted for approval MUST have a 'http://jabber.org/protocol/muc#msg_moderate' namespace extension to indicate to the room that this message is for moderation.

Example 5. Submitting a message for moderation

<message
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit'
    type='groupchat' id='client_id'>
  <body>Harrpier cries: 'tis time, 'tis time.</body>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
</message>

If the room is not configured with message moderation, has moderation stopped or the sender has voice - then an error is returned to the sender. The room MUST send an error to the submitter if the message includes any other tag within the msg_moderate namespace which is not appropriate for message submission.

A message submitted by the user SHOULD contain an 'id' attribute to the message stanza. If the client submit's multiple messages for moderation, the id SHOULD be used to disambiguate and identify the acknowledgements for each message from the room. If the submitted message has an 'id', it MUST be included in the response from the room.

Example 6. Error returned to sender in case of error

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error' id='client_id'>
  <body>Harrpier cries: 'tis time, 'tis time.</body>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate'/>
  <error code='409' type='cancel'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

If the message submission is valid and message moderation is active, the room will acknowledge reciept of the message and assign an opaque 'message moderation id' (moderation_message_id in examples) which will be used by the room to identify the submited message. The actual message moderation (approval or rejection) could happen after some time, hence room sets the state of the message to 'pending'.

Example 7. Room acknowledging reciept of message to the sender

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='groupchat' id='client_id'>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate' >
     <action type='pending' id='moderation_message_id'/>
  </x>
</message>

3.5 Room managing messages

The room SHOULD NOT directly act on the submitted messages and SHOULD forward this to a active message moderator to approve or deny the message submission. (Defining the room and moderator interaction is outside the scope of this xep)

On reception of the moderator's response, the room then processes the message appropriately and also notifies the submitter of the result (accepted|rejected|error). The message is identified by the 'message moderation id' specified in the action element,

Example 8. Room rejects the Message

<message
     to='hag66@shakespeare.lit/pda'
     from='darkcave@macbeth.shakespeare.lit'
     type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#msg_moderate'>
       <action type='rejected' id='moderation_message_id'>
           <reason>you said that already</reason>
       </action>
   </x>
</message>

Example 9. Room accepts the message

<message
     from='darkcave@macbeth.shakespeare.lit'
     to='hag66@shakespeare.lit/pda'
     type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#msg_moderate'>
       <action type='accepted' id='moderation_message_id'>
           <reason>what a good idea!</reason>
       </action>       
   </x>
</message>
It is possible for an error to get sent to the submitter for a pending message.

Example 10. Room returns an error for a pending message

<message
     from='darkcave@macbeth.shakespeare.lit'
     to='hag66@shakespeare.lit/pda'
     type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#msg_moderate'>
       <action type='error' id='moderation_message_id'>
           <reason>All message moderators have left.</reason>
       </action>       
   </x>
</message>

The 'message moderation id' is considered invalid after submitter recieves an accepted, rejected or error notifcation from the room. If the room accepts the message (because of moderator approval) then it will broadcast the message to all the occupants of the room.

Example 11. Server broadcasts accepted message to all occupants

<message
     from='darkcave@macbeth.shakespeare.lit/thirdwitch'
     to='crone1@shakespeare.lit/desktop'
     type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
     from='darkcave@macbeth.shakespeare.lit/thirdwitch'
     to='wiccarocks@shakespeare.lit/laptop'
     type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
     from='darkcave@macbeth.shakespeare.lit/thirdwitch'
     to='hag66@shakespeare.lit/pda'
     type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

3.6 Submitter cancelling message

Since the message acceptance/rejection could take place after an extended amount of time, it might become necessary for the submitter to cancel the message.

When the submitter makes such a request, the room SHALL make a best case effort to satisfy this request. But such a request could fail for a variety of reasons including :

If message gets cancelled, then any subsequent request from submitter for that moderator_message_id MUST result in error.

Example 12. Submitter requests cancellation of message

<message
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit'
    type='groupchat'>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate' >
     <action type='cancel' id='moderation_message_id'/>
  </x>
</message>

Example 13. Room successfully cancels the message

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate'>
     <action type='cancelled' id='moderation_message_id'/>
  </x>
</message>

If the room cannot cancel the message, it MUST send back the message stanza with type set to 'error'.

In this case, the message is still active and submitted - and could result in a future approval/rejection from a moderator.

Example 14. Room unable to cancel the message

<message
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc#msg_moderate'>
     <action type='cancel' id='moderation_message_id'/>
  </x>
</message>

4. Security Considerations

Security considerations applicable to multi user chat are applicable here.

5. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [1].

6. Jabber Registrar Considerations

The XMPP Registrar [2] includes the following information in its registries.

6.1 Protocol Namespaces

The XMPP Registrar includes the following message moderation related namespaces in its registry of protocol namespaces:

6.2 Service Discovery Features

The following features related to a MUC room can be discovered by means of Service Discovery.

Registry Submission

<var>
  <name>http://jabber.org/protocol/muc#msg_moderate</name>
  <desc>Indicates that room supports message moderation</desc>
  <doc>msg_moderate XEP proposal</doc>
</var>

7. XML Schema

7.1 http://jabber.org/protocol/muc#msg_moderate

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc#msg_moderate'
    xmlns='http://jabber.org/protocol/muc#msg_moderate'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in submitter XEP (TODO - add link ?).
    </xs:documentation>
  </xs:annotation>
  
 <xs:element name='x'>
    <xs:complexType>
      <xs:element ref='action'/>
    </xs:complexType>
  </xs:element> 

  <xs:element name='action'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='type' use='required'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='start' />
            <xs:enumeration value='stop' />
            <xs:enumeration value='pending' />
            <xs:enumeration value='accepted' />
            <xs:enumeration value='rejected' />
            <xs:enumeration value='cancel' />
            <xs:enumeration value='cancelled' />
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name='id' type='xs:string' use='optional' />
    </xs:complexType>
  </xs:element>
  <xs:element name='reason' type='xs:string'/>
</xs:schema>

8. Acknowledgements

The authors would like to thank the following individuals for their many helpful comments on various drafts of this proposal: Jacques Belissent.

Notes

1. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

2. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

Revision History

Version 0.0.1 (2007-05-22)

Initial submission.

(mm,rs)

END