Hi All

Thanks to everyone who responded with feedback on the XEP-0425 Last Call, especially Marvin for the well founded criticism and helpful suggestions.

I've made a PR which I believe addresses the main criticisms and suggestions.
https://github.com/xsf/xeps/pull/1271

To recap:

1. Remove the dependency on XEP-0422 Message Fastening (and thereby use direct child of IQ) 2. Rename to 'Moderated Message Retraction' and focus only on the retraction use-case
3. Ensure compatibility with clients that only implement XEP-0424
4. Clarify the purpose of the reason element

Also, my apologies for taking so long to respond.

All the best
JC


On 07.12.21 19:45, Marvin W wrote:
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
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to