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
26 Mar
26 Mar
1:02 p.m.
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.
1:19 p.m.
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
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
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. 
1:53 p.m.
Hi Matthew,
On 26/03/2026 14.19, Matthew Wild wrote:
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
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
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.
2:14 p.m.
New subject: Breaking changes vs namespace versioning
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(a)geekplace.eu> wrote:
Hi Matthew,
On 26/03/2026 14.19, Matthew Wild wrote:
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)?
On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
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.
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. 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
27 Mar
27 Mar
7:19 a.m.
New subject: Breaking changes vs namespace versioning
On 26/03/2026 15.14, Matthew Wild wrote:
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.
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
Hi Florian,
On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo(a)geekplace.eu> wrote:
Unfortunately, and as far as I can tell, it is not documented.
On 26/03/2026 14.19, Matthew Wild wrote:
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"?).
On Thu, 26 Mar 2026 at 13:02, Stephen Paul
Weber
<singpolyma(a)singpolyma.net> wrote:
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.
> 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.
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.
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".
28 Mar
28 Mar
3:20 p.m.
New subject: Breaking changes vs namespace versioning
On Fri, 27 Mar 2026 at 07:20, Florian Schmaus <flo(a)geekplace.eu> wrote:
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.
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 26/03/2026 15.14, Matthew Wild wrote:
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...
Hi Florian,
On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo(a)geekplace.eu> wrote:
> On 26/03/2026 14.19, Matthew Wild wrote:
>> On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
>> <singpolyma(a)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.
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. 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".
5:57 p.m.
New subject: Breaking changes vs namespace versioning
On Sat, 28 Mar 2026, 15:20 Dave Cridland, <dave(a)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
30 Mar
30 Mar
11:14 a.m.
New subject: Breaking changes vs namespace versioning
On 26 Mar 2026, at 14:14, Matthew Wild
<mwild1(a)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
6
days inactive
10
days old
8 comments
5 participants
participants (5)
-
Dave Cridland -
Florian Schmaus -
Kevin Smith -
Matthew Wild -
Stephen Paul Weber