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 -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org