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.