26 Mar
2026
26 Mar
'26
12:39 p.m.
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