Sun, 11 Mar 2018 21:21:30 GMT
In theory, XMPP needs no versioning: There is a mighty base-protocol with lots of extensions, and the extensions just need to be negotiated and can then be used. But then again, there are lots of xmpp clients out there with different sets of extensions. Some are older and unmaintained and do not support crucial new XEPs. Some are too new to support all XEPs. Nevertheless, all of them can be called "XMPP Clients". Because "XMPP" is a base-protocol with many extensions.
In my opinion, it would therefore be a good thing to take sets of such XEPs, and define "XMPP Levels" for them. "XMPP Level 1" could be the base protocol, while "XMPP Level 2" could contain the crucial XEPs for modern mobile communication, like Stream Management, Client State Indication, Message Carbons and maybe Cloud Push. Then, clients supporting only Level 1 would still be XMPP Clients, but maintained modern clients which support modern XEPs can call themselves "XMPPL2-Clients".
From a technical perspective, this seems random. But from a user perspective, knowing about "supported XEPs" is not really something desirable, whereas knowing "XMPPL2 New, XMPPL1 Old" is something that can be told to everyone. It would furthermore stigmatize older unmaintained XMPP Clients – which is a good thing in my opinion.
In some situations, some XEPs are not useful. Like for the BitlBee gateway, which is meant to run on servers with high connectivity, Stream Management seems not that important. But then they still could say "XMPPL2 except for Stream Management" – it is clear that especially open source projects will not always be up to date or will sometimes deliberately not comply with such versioning. But it would still be better than today's very chaotic system, in my opinion.