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

On Tue, 6 Jan 2026 at 16:48, Philipp Hörist <[email protected]> wrote:

> Hi,
>
> Here my suggestions again for the XEP
>
> 1. State clearly in the introduction that this XEP defines a generic
> element for re-use in other, not yet defined, specs.
>    - This justifies the generic XEP title (which otherwise wouldnt, if
> this is *just* an extension for blocking)
>    - It takes responsibility for the generic element re-use use case, this
> may be relevant if there are changes requested in the future, which have
> nothing to do with the blocking use case. As currently the author could
> rightfully refuse any changes that don't affect the blocking command use
> case.
>
>
I generally agree with this. I thought it was clear from the outset, but on
a re-read I agree it suggests the syntax is only for this purpose in the
introduction, whereas the rest of the document separates the payload and
the blocking extension.


> 2. Clearly separate the second goal of the XEP, to define one such context
> where the generic element is used.
>    - Clear separation helps to understand the intentions and that the XEP
> has two goals
>
>
Clarifying XEPs is always good.


> 3. Define a disco feature that mentions the context, e.g.
> urn:xmpp:blocking:reporting:1
>    - Because it is intended that the generic element is used in multiple
> other contexts, the first use case should not claim the generic namespace
> urn:xmpp:reporting:1.
>    - Because this spec is also an extension of blocking, a natural
> candidate would be urn:xmpp:blocking:reporting:1, which makes it clear that
> this functionality is depended on the blocking spec.
>
>
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).

>
>
> Regards
> Philipp
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]