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. 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 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. Regards Philipp _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
