Hi, Today I read through the latest revisions of XEP-0377, and a number of things stood out. I've broken this email into a section per issue. Namespace versioning -------------------------- Version 0.4.0 of XEP-0377 contains schema changes without changing the namespace. This contravenes XEP-0053, which states: "While the XEP is in the Experimental state, if appropriate and in consultation with the author(s), the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "0" to "1"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol." Generally, adding previously undefined elements is considered to be a breaking change that requires a new namespace, especially in a protocol that is already deployed. Possible remedies: Given that the current namespace is already implemented and deployed, I would have preferred to see this XEP advanced than modified. However, if there is consensus that we really need these new rules, they could be tacked on in a new namespace such as 'urn:xmpp:reporting:1#processing'. There is precedent for this approach in other XEPs, including XEP-0313. Failing that, we would have to update to 'urn:xmpp:reporting:2' and update all implementations (and this also is the only way to guarantee that implementations will honour the processing rules). Extensibility via elements ------------------------ The new version created a registry to allow new processing options to be defined. However it does this via elements. For the reasons above, this simply can't work - the schema would have to be updated every time a new processing rule is added. Especially once the XEP is advanced, schemas simply don't change like this. They get coded into implementations, and implementations would be free to reject unexpected elements. Instead, a valid approach would be to define the rules as strings (URIs are a common choice, but not strictly required) and have these passed as attribute values or character data. For example: <processing xmlns='urn:xmpp:reporting:1#processing'> <allow>origin</allow> <allow>third-party</allow> </processing> Thoughts on processing rules in general ----------------------- I get why the processing rules were added. However I really think they are approaching the problem backwards. As a service operator, receiving a report that says "here is a problem, but I forbid you from doing anything about it" is a rather silly situation. It would almost be better to not receive the report at all. For a long time, this was why multiple client developers said they weren't interested in even implementing reporting - because nothing useful actually happened on the server side, so the reports were at best logged and at worst discarded. A better approach is to have the server tell the client what will/may happen to reports that are submitted (and then give the user the choice of whether to submit or not). In most online services this disclosure happens in the Terms of Service and/or Privacy Policy. It is then up to the implementation and service operator to decide what (and how much) to share from reports, when to share them, and with whom. Per various worldwide laws, these things should often already be disclosed, regardless of the protocol layer in use. Renaming ------------ This is a more minor point, but I had planned to reuse the reporting payload in protocols other than XEP-0191: Blocking Command, and this reuse was definitely on the table at the summit where the protocol was initially discussed. I think the new title feels like it is discouraging such reuse, compared to the previous title and contents (where usage within XEP-0191 was provided as an initial location where reports should happen). I intend to submit protoXEPs based on this specification with or without any of the points in this email being addressed, I only thought I should provide the feedback as I saw the new changes and they surprised me. Regards, Matthew