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