Hello everyone,

Thank you for the feedback provided during the Last Call. I would like to respond and clarify my intent as a co-author of XEP-0377.

Several comments suggest that the XEP could or should define a set of generic, reusable base elements for reporting, with the Blocking Command merely being one example use case. In contrast, the introduction of the XEP deliberately limits its scope to extending the Blocking Command, and this is intentional.

To be explicit: I do not see the purpose of XEP-0377 as defining a generic reporting or abuse framework for XMPP. I see it as a pragmatic addition to the Blocking Command, and nothing more. If parts of the syntax later turn out to be reusable in other contexts, that is a welcome outcome, but an accidental one rather than a design goal.

I fully agree that MUCs are a significant part of XMPP messaging. However, since XEP-0377 does not aim to be a generic solution to spam reporting or abuse handling, I consider MUC-related reporting out of scope here. To my knowledge, application of the Blocking Command itself is not a major or established concept in the context of MUCs, which further supports keeping this XEP narrowly focused.

I also agree that there is a broader need for additional specifications in this space, and that the overall document landscape should be coherent and forward-looking. However, I do not believe that fulfilling that need depends on XEP-0377 becoming a generic base specification. My preference is to let this XEP progress as originally intended: a low-complexity, pragmatic extension point for reporting spam in the context of functionality that users already employ when reacting to spam, namely blocking the sender.

My concern is that reworking XEP-0377 into a generic reporting base risks losing precisely those qualities: pragmatism and low complexity. I suspect that the lack of widely deployed generic spam-processing solutions in XMPP today is at least partly due to the complexity and ambition of such designs.

Most of the Last Call feedback appears to focus on structure and clarity of scope, and is otherwise positive about the XEP's usefulness and adoption, with several indications of existing or planned implementations. Based on this, my intent is to improve the XEP so that it is clearer and better aligned with its intended goal, including a new title and other editorial changes, while accepting that this goal is less ambitious than some would prefer.

One suggestion was to allow multiple reporting reasons (for example, SPAM, PORN, and CSAM) using an element instead of an attribute. I am leaving this out of scope for now, as supporting multiple reasons adds complexity, risks end-user confusion, and could lead to attempts to game the system. The XEP will remain simple and focused on the typical blocking use case.

Another concern raised was about anonymization: "Servers MAY anonymize any submission to third-party services" and whether there should be a way to indicate if anonymization was applied. This has now been addressed in the XEP: the specification explicitly defines a single, acceptable anonymization method: removing the 'to' attribute from the reported message. This makes it immediately clear when anonymization has been applied, without requiring additional signaling, while still allowing servers the choice to anonymize or not.

I have prepared for the changes in this pull request: https://github.com/xsf/xeps/pull/1506 

My suggestion is that if, in the future, a new XEP emerges that defines a true base-level reporting framework, whether or not it builds on XEP-0377, we can then revisit XEP-0377 and evaluate whether it should defer to or integrate with that work. Until such a specification exists, I believe there is significant value in the current pragmatic approach and in allowing this XEP to advance in its present form.