26 Mar
2026
26 Mar
'26
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.