Re: LAST CALL: XEP-0377 (Spam Reporting)

Stephen Paul Weber <[email protected]> Wed, 24 Dec 2025 09:58:45 -0500
Newsgroups	gmane.network.jabber.standards-jig
Message-ID	<[email protected]>
>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.

I agree with this. This XEPs purpose is to define a generic syntax for use 
in all reporting contexts (and is already being used in contexts besides 
what the XEP explicitly defines) and this should be clear to the reader.

>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.
>
>So e.g. urn:xmpp:blocking:reporting:1

Hmm. I have no strong feeling here. Supporting both blocking and reporting 
features would mean you support blocking with nested reporting. I believe 
that is the current intent. Having an explicit blocking+reporting feature as 
well could be fine I don't mind it but I don't know that we need it either.

>As such i would propose to move the section "Use with the Blocking Command" 
>and the disco feature to XEP-0191, and revert this XEP to a base XEP which 
>defines just the reporting elements.

It cannot go in 0191 as that is stable, and besides it is an extension to 
0191 so doesn't belong there. It either belongs here or in yet another xep.  
	  I think we have quite some tradition of the first XEP for a new syntax 
also defining at least one way to use that syntax (otherwise the XEP by 
itself is useless) and I support that formulation here.

>There is nothing out there that defines how messages or users in a MUC can 
>be reported, and MUC is a considerable part of XMPP messaging. Its very 
>likely that we want and need to fill this gap soon. So i urge who ever 
>needs to vote on these specs, to think 2 steps into the future and guide 
>authors so we have a coherent document landscape.

I think this XEP's syntax can directly support the MUC use case, but I agree 
we will need another XEP that explicitly states that once an implementation 
exists. I don't think it needs to be added here per se.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 833 B)