Re: Breaking changes vs namespace versioning

On Fri, 27 Mar 2026 at 07:20, Florian Schmaus <[email protected]> wrote:

> On 26/03/2026 15.14, Matthew Wild wrote:
> > Hi Florian,
> > On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <[email protected]> wrote:
> >> On 26/03/2026 14.19, Matthew Wild wrote:
> >>> On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
> >>> <[email protected]> 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.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]