Hi, Answering the standard questions first.
> 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes. > 2. Does the specification solve the problem stated in the introduction > and requirements? No. The introduction explains different moderator actions: - "retracting them [groupchat messages] from the groupchat history" - "correct a message on another user's behalf" - "flag a message as inappropriate without requiring that it be retracted" The XEP only defines means for retracting messages. While the syntax suggests that other moderator actions might be added (by putting something else in <moderate(d)> than <retract />), the semantics described only make sense for retraction. > 3. Do you plan to implement this specification in your code? If not, > why not? Not really. The current specification has too many issues to be considered sensible to implement in production IMO. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? No. There is absolutely no normative description of the syntax being used. The examples show a <reason> element inside <moderate>/<moderated> which is not described anywhere outside the examples (and also does not appear in the XML schema) - The XEP in its current form is not a generic message moderation XEP as suggested in its name, abstract and introduction. - The XEP depends on XEP-0424 (Message retraction) while not being compatible at all or taking any of its semantics. The only thing taken from XEP-0424 is the syntax element <retract /> which is used in a different way as described in XEP-0424. - The XEP uses <apply-to> element from XEP-0422 in an IQ. However XEP-0422 only describes means and rules for using <apply-to> inside messages. According to RFC-6121 §6, `the specific semantics needed to complete particular use cases are defined in all instances by the extended namespace that qualifies the direct child element of an IQ stanza of type "get" or "set"`. However, the semantics of the IQ shown in example 4 of XEP-0425 are defined by the second level child of the IQ stanza (the <moderate> inside the <apply-to>). Suggestions for changes: - Focus on solely providing the feature of moderated message retraction in all parts of the specification. - Use own direct child for IQ to MUC service instead of <apply-to>. - Clarify (optional) usage of <reason> (this was already discussed on-list IIRC). - Choose syntax of message sent to participants and tombstones such that clients that only implement XEP-0424 will understand the message retraction (maybe losing information that retraction was performed by a moderator). For example by placing the <moderated> inside the <retract> instead of the other way round. Alternatively consider moderated retraction and self retraction completely independent features that don't share any syntax elements. IMO, this XEP needs further work before being ready to move to Stable. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
