Hi, > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > > 2. Does the specification solve the problem stated in the introduction > and requirements?
Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? In Gajim we have implemented it. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? Yes. > Your feedback is appreciated! The XEPs limits its own scope in the introduction to extending blocking command. But then defines all report elements in a generic way and in the end just defines a section "Use with the Blocking Command" which makes you believe its intended for reporting to be used somewhere else in the future. Also the title of the XEP implies its a general solution, when the introduction says the opposite. 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. 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 it should be a child of blocking, as it extends the blocking spec. 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. 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. This does not mean that this spec needs to fill the gap for MUC, but it should not be written oblivious to what we know we need soon. Instead it should lay the groundwork so others can extend on it. Regards Philipp _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
