Problems with latest XEP-0377 updates
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
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
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
Agreed.
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a requirement for XMPP implementations. But for a specific implemented namespace defined in a XEP, it is absolutely valid for implementations to reject elements which were not defined in the namespace's schema. We even have error conditions explicitly defined for use in such cases. I am personally not one of the people who feel most strongly about this, and there have been times in the past where I personally would have preferred to sneak in some elements to established namespaces (if the disruption would be lower than that caused by a namespace change). However it is a position that we have taken as a community since the namespace versioning was introduced, that generally schemas do not change after publication (I can imagine exceptions for very young unimplemented experimental XEPs). This is because some applications do choose the strict validation option (sometimes this is for technical reasons, because it ensures they can accurately translate XML to custom data structures). That many implementations will happily ignore extra elements just adds to the problems around this particular change, given the nature of these elements being user opt-ins (if any clients are sending them today, they are 100% being ignored). It's actually a perfect example of why namespace versioning was introduced. Regards, Matthew
Hi Matthew, On 26/03/2026 14.19, Matthew Wild wrote:
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a requirement for XMPP implementations. But for a specific implemented namespace defined in a XEP, it is absolutely valid for implementations to reject elements which were not defined in the namespace's schema. We even have error conditions explicitly defined for use in such cases.
I am personally not one of the people who feel most strongly about this, and there have been times in the past where I personally would have preferred to sneak in some elements to established namespaces (if the disruption would be lower than that caused by a namespace change). However it is a position that we have taken as a community since the namespace versioning was introduced, that generally schemas do not change after publication (I can imagine exceptions for very young unimplemented experimental XEPs). This is because some applications do choose the strict validation option (sometimes this is for technical reasons, because it ensures they can accurately translate XML to custom data structures).
That many implementations will happily ignore extra elements just adds to the problems around this particular change, given the nature of these elements being user opt-ins (if any clients are sending them today, they are 100% being ignored). It's actually a perfect example of why namespace versioning was introduced.
I am sorry, but this is not how I perceive the situation. I think we both agree that implementations are supposed to ignore unknown elements. However, if I understood you correctly, you limit this to unknown elements in an different namespace from the parent element. I, on the other hand, believe this is also true for unknown elements in the same namespace. In general, we want it to be fine for recipients to ignore unknown elements (and probably attributes). This allows us to evolve a protocol as long as possible without namespace bumps. Obviously, this only works if the new element (or attribute) can be safely ignored by the recipient without breaking functionality. For example, hints that the recipient could process, but doesn't have to. I am not sure why we should artificially limit ourselves here and create an extra burden due to additional namespace bumps if we don't have to? And that's me saying this. The person who also argues for strict verification because it eventually increases the robustness of the overall ecosystem. For example, rejecting "foo" as an the value of an attribute declared to be xs:int, as it is clearly a violation of the specification. But why should we reject something if we don't know what it is supposed to be, especially if there are obvious drawbacks associated with such an approach? - Flow
Hi Florian, Since we're taking a tangent into namespace versioning, I've changed the subject to not distract from the XEP-0377 feedback thread. On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo@geekplace.eu> wrote:
Hi Matthew,
On 26/03/2026 14.19, Matthew Wild wrote:
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a requirement for XMPP implementations. But for a specific implemented namespace defined in a XEP, it is absolutely valid for implementations to reject elements which were not defined in the namespace's schema. We even have error conditions explicitly defined for use in such cases.
I am personally not one of the people who feel most strongly about this, and there have been times in the past where I personally would have preferred to sneak in some elements to established namespaces (if the disruption would be lower than that caused by a namespace change). However it is a position that we have taken as a community since the namespace versioning was introduced, that generally schemas do not change after publication (I can imagine exceptions for very young unimplemented experimental XEPs). This is because some applications do choose the strict validation option (sometimes this is for technical reasons, because it ensures they can accurately translate XML to custom data structures).
That many implementations will happily ignore extra elements just adds to the problems around this particular change, given the nature of these elements being user opt-ins (if any clients are sending them today, they are 100% being ignored). It's actually a perfect example of why namespace versioning was introduced.
I am sorry, but this is not how I perceive the situation.
I think we both agree that implementations are supposed to ignore unknown elements. However, if I understood you correctly, you limit this to unknown elements in an different namespace from the parent element. I, on the other hand, believe this is also true for unknown elements in the same namespace.
In general, we want it to be fine for recipients to ignore unknown elements (and probably attributes). This allows us to evolve a protocol as long as possible without namespace bumps.
This is news to me. Is this documented anywhere? My understanding of community consensus is that introduction of new elements and attributes constitutes a breaking change. Maybe I read the consensus wrong, or attitudes have shifted (was this ever documented beyond the text I quoted in XEP-0053 which doesn't exactly define "breaking change"?). If I implement strict schema validation in my implementation, and then the schema for the namespace changes, this is a "breaking change" for me. Unless we document somewhere that XMPP implementations should be forgiving of unknown elements/attributes (even in namespaces they believe they understand)?
Obviously, this only works if the new element (or attribute) can be safely ignored by the recipient without breaking functionality. For example, hints that the recipient could process, but doesn't have to.
Noted. Though in the case of XEP-0377 which sparked this discussion, it clearly does not fall into this category - the XEP introduced various requirements determined by the presence or absence of the added elements, which existing implementations of the XEP would automatically violate.
I am not sure why we should artificially limit ourselves here and create an extra burden due to additional namespace bumps if we don't have to?
If everyone agrees that it's fine, I'm fine with that! As I noted in my previous mail, I don't feel strongly about this and none of my implementations generally reject unknown elements.
And that's me saying this. The person who also argues for strict verification because it eventually increases the robustness of the overall ecosystem. For example, rejecting "foo" as an the value of an attribute declared to be xs:int, as it is clearly a violation of the specification.
I don't really understand how you can be in favour of strict and relaxed processing at the same time. But I don't necessarily need to understand :) It seems maybe we just have different ideas of what "strict verification" is. I think validating xs:int contents is just normal expected behaviour, I wouldn't call that "strict". Regards, Matthew
On 26/03/2026 15.14, Matthew Wild wrote:
Hi Florian, On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo@geekplace.eu> wrote:
On 26/03/2026 14.19, Matthew Wild wrote:
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a requirement for XMPP implementations. But for a specific implemented namespace defined in a XEP, it is absolutely valid for implementations to reject elements which were not defined in the namespace's schema. We even have error conditions explicitly defined for use in such cases.
I am personally not one of the people who feel most strongly about this, and there have been times in the past where I personally would have preferred to sneak in some elements to established namespaces (if the disruption would be lower than that caused by a namespace change). However it is a position that we have taken as a community since the namespace versioning was introduced, that generally schemas do not change after publication (I can imagine exceptions for very young unimplemented experimental XEPs). This is because some applications do choose the strict validation option (sometimes this is for technical reasons, because it ensures they can accurately translate XML to custom data structures).
That many implementations will happily ignore extra elements just adds to the problems around this particular change, given the nature of these elements being user opt-ins (if any clients are sending them today, they are 100% being ignored). It's actually a perfect example of why namespace versioning was introduced.
I am sorry, but this is not how I perceive the situation.
I think we both agree that implementations are supposed to ignore unknown elements. However, if I understood you correctly, you limit this to unknown elements in an different namespace from the parent element. I, on the other hand, believe this is also true for unknown elements in the same namespace.
In general, we want it to be fine for recipients to ignore unknown elements (and probably attributes). This allows us to evolve a protocol as long as possible without namespace bumps.
This is news to me. Is this documented anywhere? My understanding of community consensus is that introduction of new elements and attributes constitutes a breaking change. Maybe I read the consensus wrong, or attitudes have shifted (was this ever documented beyond the text I quoted in XEP-0053 which doesn't exactly define "breaking change"?).
Unfortunately, and as far as I can tell, it is not documented.
Obviously, this only works if the new element (or attribute) can be safely ignored by the recipient without breaking functionality. For example, hints that the recipient could process, but doesn't have to.
Noted. Though in the case of XEP-0377 which sparked this discussion, it clearly does not fall into this category - the XEP introduced various requirements determined by the presence or absence of the added elements, which existing implementations of the XEP would automatically violate.
Yes, I agree. To make matters more complex, this is another distinct discussion. Namespace bumps are required for breaking changes. However, I believe parts of your community believe that namespace bumps can be omitted for experimental XEPs, probably because that kind of agility is good to have when experimenting with a new XEP. But again, different discussion and this clearly is in violation of the XEP-0053 requirement you cite.
And that's me saying this. The person who also argues for strict verification because it eventually increases the robustness of the overall ecosystem. For example, rejecting "foo" as an the value of an attribute declared to be xs:int, as it is clearly a violation of the specification.
I don't really understand how you can be in favour of strict and relaxed processing at the same time. But I don't necessarily need to understand :)
It seems maybe we just have different ideas of what "strict verification" is. I think validating xs:int contents is just normal expected behaviour, I wouldn't call that "strict".
I didn't explain that properly, let me try again and let us ignore terminology like "strict verification" for now. We find information about the XML structure used by XMPP in our XML schemas. For example, the type of an attribute, or the valid values of an attribute, or how often a child element can appear. If something isn't specified there, then it is unknown. Now, I know that XSD rules are very strict. If something appears that isn't specified it doesn't follow the schema. However, we agree that elements/attributes in a different namespace are fine. This is already something that is impossible with the majority of schemas our XEPs carry (because they don't declare xs:any or xs:anyAttribute). I just extend this practice of extensibility to attributes/elements in the same namespace. Because why should deny ourselves the opportunity to evolve a XEP without a namespace bump, if the newly introduced elements/attributes are backwards compatible? - Flow
On Fri, 27 Mar 2026 at 07:20, Florian Schmaus <flo@geekplace.eu> wrote:
On 26/03/2026 15.14, Matthew Wild wrote:
Hi Florian, On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo@geekplace.eu> wrote:
On 26/03/2026 14.19, Matthew Wild wrote:
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
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.
Adding new elements seems like the least breaking change? Unless they're marked as manadatory, any implementation needs to be able to handle unknown child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a requirement for XMPP implementations. But for a specific implemented namespace defined in a XEP, it is absolutely valid for implementations to reject elements which were not defined in the namespace's schema. We even have error conditions explicitly defined for use in such cases.
I am personally not one of the people who feel most strongly about this, and there have been times in the past where I personally would have preferred to sneak in some elements to established namespaces (if the disruption would be lower than that caused by a namespace change). However it is a position that we have taken as a community since the namespace versioning was introduced, that generally schemas do not change after publication (I can imagine exceptions for very young unimplemented experimental XEPs). This is because some applications do choose the strict validation option (sometimes this is for technical reasons, because it ensures they can accurately translate XML to custom data structures).
That many implementations will happily ignore extra elements just adds to the problems around this particular change, given the nature of these elements being user opt-ins (if any clients are sending them today, they are 100% being ignored). It's actually a perfect example of why namespace versioning was introduced.
I am sorry, but this is not how I perceive the situation.
I think we both agree that implementations are supposed to ignore unknown elements. However, if I understood you correctly, you limit this to unknown elements in an different namespace from the parent element. I, on the other hand, believe this is also true for unknown elements in the same namespace.
In general, we want it to be fine for recipients to ignore unknown elements (and probably attributes). This allows us to evolve a protocol as long as possible without namespace bumps.
This is news to me. Is this documented anywhere? My understanding of community consensus is that introduction of new elements and attributes constitutes a breaking change. Maybe I read the consensus wrong, or attitudes have shifted (was this ever documented beyond the text I quoted in XEP-0053 which doesn't exactly define "breaking change"?).
Unfortunately, and as far as I can tell, it is not documented.
I concur. There's nothing I can find in RFCs or XEPs on this, nor on what "backwards compatible" actually means with respect to namespace versioning. There was consensus at the time, I think, that we had consensus on what that meant, but...
Obviously, this only works if the new element (or attribute) can be safely ignored by the recipient without breaking functionality. For example, hints that the recipient could process, but doesn't have to.
Noted. Though in the case of XEP-0377 which sparked this discussion, it clearly does not fall into this category - the XEP introduced various requirements determined by the presence or absence of the added elements, which existing implementations of the XEP would automatically violate.
Yes, I agree. To make matters more complex, this is another distinct discussion. Namespace bumps are required for breaking changes. However, I believe parts of your community believe that namespace bumps can be omitted for experimental XEPs, probably because that kind of agility is good to have when experimenting with a new XEP. But again, different discussion and this clearly is in violation of the XEP-0053 requirement you cite.
FWIW, the namespace versioning concept was introduced precisely to allow experiment XEPs to change namespaces easily, maintaining the agility, without worrying about deployment. So it's almost the exact opposite case to the "However" sentence above. We introduced these so we could maintain the agility we already had without worrying about deployment. Changing XEPs in backwards incompatible ways without changing the namespace is bad for the network, and this is definitely a hill I will die on - because I'm old and grey enough to remember what that was like.
And that's me saying this. The person who also argues for strict verification because it eventually increases the robustness of the overall ecosystem. For example, rejecting "foo" as an the value of an attribute declared to be xs:int, as it is clearly a violation of the specification.
I don't really understand how you can be in favour of strict and relaxed processing at the same time. But I don't necessarily need to understand :)
It seems maybe we just have different ideas of what "strict verification" is. I think validating xs:int contents is just normal expected behaviour, I wouldn't call that "strict".
I didn't explain that properly, let me try again and let us ignore terminology like "strict verification" for now.
We find information about the XML structure used by XMPP in our XML schemas. For example, the type of an attribute, or the valid values of an attribute, or how often a child element can appear. If something isn't specified there, then it is unknown.
Now, I know that XSD rules are very strict. If something appears that isn't specified it doesn't follow the schema. However, we agree that elements/attributes in a different namespace are fine. This is already something that is impossible with the majority of schemas our XEPs carry (because they don't declare xs:any or xs:anyAttribute).
I just extend this practice of extensibility to attributes/elements in the same namespace. Because why should deny ourselves the opportunity to evolve a XEP without a namespace bump, if the newly introduced elements/attributes are backwards compatible?
Right, though "backwards compatible" in this instance has a particular meaning (in my opinion): The absence of the additional attribute or element will result in behaviour conformant to the new document. More generally, you need a namespace bump if one party that's acting in full conformance to the earliest document version using this namespace would no longer be conformant to the latest document using the same namespace - but that's ignoring any XML Schema, and given we don't require those for Experimental that seems fair. (XEP-0001 section 9.1 note it is required for Stable). FWIW, I don't think this definition can be applied to the changes in XEP-0377, based on a very quick skim of the document and this thread. Now... If someone wants to argue that Experimental XEPs should have strictly stable schemas, then I think we've a problem, because Experimental XEPs aren't meant to be particularly stable, and an implementation that decides to only process valid XML by the schemas really shouldn't be hardcoding Experimental XEP schemas at all in my view - in which case they (hopefully) fall into the xs:any shaped trapdoors and pass. Namespace versioning is (or was, at least) an attempt to stabilise the namespaces - not the schemas as such - enough that experimental implementation was "safe" on the open network: * Safe in the sense that as the protocol changed, it wouldn't fail to interoperate because of weird old versions. * Safe in the sense that we didn't have to feel beholden to weird old versions when changing the protocol. * Safe in the sense that if you wanted to implement a "late stage" Experimental, it was very likely to keep working when it was Approved as Stable, so you didn't get penalised for being proactive. Prior to namespace versioning, we used urn:xmpp:tmp:* namespaces, which were very much wild-west, and replaced on advancement to Stable with a "real" namespace. Dave.
On Sat, 28 Mar 2026, 15:20 Dave Cridland, <dave@cridland.net> wrote:
Right, though "backwards compatible" in this instance has a particular
meaning (in my opinion):
The absence of the additional attribute or element will result in behaviour conformant to the new document.
More generally, you need a namespace bump if one party that's acting in full conformance to the earliest document version using this namespace would no longer be conformant to the latest document using the same namespace - but that's ignoring any XML Schema, and given we don't require those for Experimental that seems fair. (XEP-0001 section 9.1 note it is required for Stable).
FWIW, I don't think this definition can be applied to the changes in XEP-0377, based on a very quick skim of the document and this thread.
It's exactly what has happened with XEP-0377. The new text says (quoted verbatim): "Servers MUST NOT process a report if the report that do not explicitly include the corresponding processing option." All existing implementations do not send nor check for the processing options, they are not aware of and cannot comply with this new requirement. As a server, I can't tell if the client doesn't support the new options or whether it explicitly didn't include them. As a server, I can't rely on the server honouring their absence and I have no way to detect this. This is a breaking change every way you look at it. Regards, Matthew
On 26 Mar 2026, at 14:14, Matthew Wild <mwild1@gmail.com> wrote: My understanding of community consensus is that introduction of new elements and attributes constitutes a breaking change.
That’s what I’ve understood. You can add new stuff without changing namespace by putting the new stuff into a new namespace, leaving the parent intact, but you don’t add new elements/attributes to an existing namespace. As with so many things, I fear this is tribal knowledge that we’ve never recorded. /K
participants (5)
-
Dave Cridland -
Florian Schmaus -
Kevin Smith -
Matthew Wild -
Stephen Paul Weber