I agree with Philipp. The entire XEP is a bit confusing when it comes to the question of scope: is it meant as a general mechanism to be used in multiple places or rather tailored to the blocking command only?
In my opinion we should define a general reporting element usable in various places and then define one (or two, see below) usage scenarios where this element can be used in the same XEP as well (e.g. use with blocking command etc.). Afaik that's what we usually do in other XEPs as well, isn't it? I think some small rewording and restructuring should be enough to reach that goal fairly easily. Also: In Monal you can outcast a channel participant in the same dialog used to moderate a message. It would be really cool to also report the user and message as spam from the same dialog as well. But since spam reporting is currently only defined for the blocking command, that isn't possible, no? I'm planning to implement that XEP in Monal as soon as reporting messages/ users in channels is somehow covered by the XEP. I had even already started to implement it, when I realized that the reporting element isn't defined for my channel moderation usecase at all. -tmolitor Am Dienstag, 6. Januar 2026, 19:00:42 CET schrieb Philipp Hörist: > Hi, > > On Tue, Jan 6, 2026, at 18:10, Dave Cridland wrote: > > The feature is specific to reporting via blocking already. Section 3 > > begins: Entities that support Service Discovery (XEP-0030) [2] and abuse > > reporting using the blocking command as defined in this spec MUST respond > > to service discovery requests with a feature of 'urn:xmpp:reporting:1'. > > > > There's no behaviour associated with the report syntax except for > > blocking, so it doesn't need another feature. > > > > I would hesitate before suggesting that one XEP should add a "sub > > namespace" to another's, I think that could get very confusing very fast. > > > > If we had another consumer of reports, then we'd have another feature for > > that mode of consumption (or production, I suppose). > Yes im aware that this generic namespace is specific for functionality with > blocking command now. I think the text regarding that is clear enough in > the XEP. > > But i think its a missed chance to choose a namespace that semantically > makes more sense. Clearly separating the definition of the generic element, > from the implementation in a specific context. > On Tue, Jan 6, 2026, at 18:06, Stephen Paul Weber wrote: > > I agree with everything except this. Why is it insufficient to say "if you > > support both blocking and reporting then you support reporting in > > blocking" ? > I wrote insufficient, when i believed it was intended that other future XEPs > also are supposed to announce urn:xmpp:reporting:1, but it seems the author > is aware and it was intended that no other XEP can announce this feature, > because it is bound to blocking command. > > Regards > Philipp > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
