I would like to hold XMPP up as an example, here. If you do not know XMPP, it is short for Extensible Messaging and Presence Protocol, a protocol for building distributed instant messaging applications. While extensibility was so important they even made it part of the protocol’s name, they did not want to end up with a runaway specification that depends on having implementers talk to each other to be working reliably.
Instead, they wrote a very strict base set of the absolute minimums required to build on XMPP, and pushed that through the IETF’s standards track, ending up with what is now RFC 6120. Acknowledging that they can never address all needs in such a strict specification document, they opened themselves for more flexibility:
This document specifies how clients connect to servers and specifies the basic semantics of XML stanzas. However, this document does not define the “payloads” of the XML stanzas that might be exchanged once a connection is successfully established; instead, those payloads are defined by various XMPP extensions. For example, [XMPP-IM] defines extensions for basic instant messaging and presence functionality. In addition, various specifications produced in the XSF’s XEP series [XEP-0001] define extensions for a wide range of applications.
They introduced XEPs, XMPP Extensions Protocols. The very first XEP ever published, XEP-0001, describes the process of getting a new XEP published to the world, and that process of that is not very hard to understand or tricky to follow. Everyone is invited to submit a proposal, you do not have to be a member of any organization, and in fact, you do not even need to maintain your own implementation. As long as your proposal follows the rules and matches the required format, it will be taken into consideration. After a proposal has been made, there is a specific chain of events, but it boils down to an open discussion on those proposals, and if there are no more doubts or things to improve, and if people agree that the proposal would be a useful thing to standardize, the proposal will eventually end up as an actual XEP.
At the time of writing, there are 151 active, draft, experimental, final, or proposed XEPs, and all of them can be found on the XMPP Standards Foundation’s website. Everyone interested in reading up on those topics, for example because they want to implement a client or a server, can find those documents there, and there is also a central infrastructure for asking questions and proposing improvements, which is open to everyone. This way, the XSF has ensured XMPP can be extended to all imaginable use cases, without ending up with watered-down or vague specifications.
If, for example, I wanted to implement an XMPP server or a client4, I could read the relevant RFCs as well as the XEPs that are relevant to my project. Some documents, like XEP-0387 for example, would even help me out deciding which XEPs are essential, by listing the things that are important when building a web client, or an advanced desktop client, or a mobile application, … There would be no need for me to talk to other XMPP server or client implementers for my implementation to work, and I could be very comfortable about the interoperability of my systems if I built them in accordance to the specifications. That is what specifications are meant to be.
