On Wed, Dec 24, 2025 at 1:13 PM Philipp Hörist <[email protected]> wrote:
> The XEPs limits its own scope in the introduction to extending blocking > command. But then defines all report elements in a generic way and in the end > just defines a section "Use with the Blocking Command" which makes you > believe its intended for reporting to be used somewhere else in the future. > Also the title of the XEP implies its a general solution, when the > introduction says the opposite. > > If this tries to define base elements for reporting and blocking command is > just an example, the introduction should say that, so that we can judge the > XEP in the last call accurately for what it tries to be. > > Further the disco feature is insufficient if this will be used as a base > spec. The disco feature should clearly state for which use case reporting is > supported, in this case Blocking Command. I think there are 2, maybe 2.5 reads at this. 1) The spec is only meant to be used with the Blocking command. In that case the section header "6. Use with Blocking command" is maybe phrased a bit awkwardly, but should be an easy fix. I think the rest of the XEP - even that part that reasons can be registered - is not in opposition of that interpretation of the XEP. 2) The spec is meant as a generic reporting that can be used outside. In that case the intro and other parts of the XEP need some (major?) rewording. A pragmatic solution to the disco feature could for example be that if blocking and reporting namespace are both announced then they should be used together. I think there is a variant of (2) in which further spam reporting processing just 'forwards' the <report/> element defined in this XEP. This means 377 remains in it’s use with the Blocking command. And any forwarding to further centralized spam processing instances get their own discovery and wrapper syntax on top of that. For clarity one could maybe rename 0377 to "User Spam Reporting" or "User-triggered spam reporting" (Not that, but you know what I mean). I think that a future "Spam collection and centralized processing" XEP "borrowing" the <report/> element from 377 is fine. Jingle Message Init for example also borrows the <reason/> from Jingle. And SIMS borrows the <file/> from jingle file transfer. Semantically I think it makes sense that "XEP-xxxx: Spam collection and centralized processing" says here is a <report/> we got from "0377: User-triggered spam reporting" let’s do something with that. But I must also admit that this is a more convenient approach that would allow us to 377 through the process and worry about further spam processing at a later stage. cheers Daniel _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
