> The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.
Na, the standardization process starts much earlier. Using the example of the IETF process, after which XMPP standardization process is largely modeled: standardization starts when you submit an I-D to IETF and/or approach an IETF WG.
> What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components? Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
Well put and I totally agree (I think no one would have a reason to disagree with that statement).
(Seemingly) conflicting extensions are another consequence of the loosely coupling between standardization and implementations. In addition, the emergence of several functionally overlapping extensions is stimulated by the freely accessible standardization process.
Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.
> Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate
I could be wrong, but that reads like you suggest that there is an alternative to the "extension model".
However, any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions.
Think about protocols like SMTP and DNS—each has a foundational core that’s been expanded upon by numerous optional features.
Na, the standardization process starts much earlier. Using the example of the IETF process, after which XMPP standardization process is largely modeled: standardization starts when you submit an I-D to IETF and/or approach an IETF WG.
> What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components? Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
Well put and I totally agree (I think no one would have a reason to disagree with that statement).