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]
