How a XEP becomes a standard

The core of XMPP belongs to the IETF. RFC 3920 and RFC 3921, published in October 2004, defined the base protocol and concluded the XMPP Working Group; RFC 6120 and RFC 6121 updated that core in 2011. Everything else, from multi-user chat to compliance suites, arrives as a numbered extension published by the XMPP Standards Foundation, and every extension carries a status: Experimental, Proposed, Stable or Final on the standards track, Active for the other types, with Deferred, Retracted, Rejected, Deprecated and Obsolete for what stalls or is superseded. That word tells you how much scrutiny a protocol has survived. The road between those words is written down in a specification of its own.

A foundation with one job

The XMPP Standards Foundation was founded in 2001, as the Jabber Software Foundation, to document, safeguard, manage and extend the wire protocols used by the developer community. It predates the RFCs. The handover to the IETF came in 2002: the JSF contributed the base Jabber protocols under the name XMPP and assigned change control to the IETF, which published the result two years later. In 2007 the organisation renamed itself the XMPP Standards Foundation, to describe more accurately a focus on protocol extensions rather than open-source software. The division has held: the IETF keeps the core, the XSF publishes everything built around it, with the declared aim of protocols anyone can implement without encumbrance.

Who is allowed to write one?

Anyone. The rules state that any individual or group may author a proposal, and that a XEP author need not be an elected member of the XSF. A submission must be presented in the XEP format and goes to a single office, the XMPP Extensions Editor; between submission and acceptance it is known informally as a “ProtoXEP”. Two conditions are not negotiable. The document must carry legal notices exactly as the XSF IPR Policy specifies, together with author information: first name, last name, email address and Jabber ID, for every author. And the author transfers ownership of the protocol, though not of implementations, to the XSF. The specification becomes the foundation’s; the code remains yours.

Five kinds of document

Not every XEP defines a protocol. Of the five types, only Standards Track does that: either a wire protocol intended to become a standard part of XMPP, or a suite that sets conformance requirements. Informational XEPs, such as the best practices for using SASL ANONYMOUS, gather guidance for implementing what already exists. Historical XEPs record protocols written before the process itself existed and still in use. Procedural XEPs define how the foundation runs its own affairs. Humorous XEPs define protocols that would never be used in the real world; they usually appear on 1 April and are automatically Active. The approving body follows the type, and the process specification draws the whole map: the XMPP Council for the first three types, the Editor for jokes, the Board or the Council for procedure.

What does Experimental actually mean?

Less than you might hope. On receipt the Editor checks the format, publishes the proposal to the inbox, announces it on the Standards list and asks the approving body to accept it. Within 14 days the chair of that body polls its members, and if nobody objects, the document becomes a XEP: the Editor assigns it a number, a type and a status of Experimental, and publishes version 0.1. The rules are blunt about what that is worth: no special criteria apply beyond acceptance and minimal formatting compliance, and Experimental status must not be construed as any level of approval by the XSF, the Council or the developer community. Implementation is encouraged, but exploratory, as a proof of concept; such code might not be appropriate for production systems.

What carries a XEP forward?

Three forces, named in the rules: rough consensus on the XSF’s public discussion lists, running code in clients, servers and libraries, and formal approval by the XMPP Council. The community reviews the document on the open lists and implements it experimentally. If the protocol fills an important need, meets rough consensus and is, preferably, backed by running code, the Council formally reviews it and votes on advancing it to Stable. While Stable, the protocol may still be refined in the light of discussion and implementation experience. Final arrives only when the XSF judges the protocol stable after at least six months, and normally more, of implementation and deployment experience. Corrections arrive as list feedback or as pull requests against the Git repository where every XEP lives; the rules treat both routes identically.

Six months is the floor

The waiting period is the point of the design. A protocol that works in one library on a good day proves little; the process wants deployment experience across clients, servers and libraries before the word Final carries weight, and the rules themselves say the wait is normally longer than the minimum. The multi-user chat extension, XEP-0045, took significant revisions as late as February 2012, eight years after the RFCs appeared. Stable, here, means reviewed and voted on, not finished; software keeps teaching specification authors lessons, and the status line records where each lesson stands.

Read the status before you rely on the number

The status line is due diligence that takes a minute. The latest versions of every XEP are published at a single canonical address on xmpp.org, where each document appears with its type and its status. Open that page, find the extension your client or server advertises, and read three things: the status, the type, and how recently the document was revised. Those three facts tell you what kind of ground you are building on.

xmpp.org is the website of the XMPP Standards Foundation. It publishes the latest version of every XEP at a single canonical address, the extensions page, and it keeps a history section that traces the protocol from Jeremie Miller’s announcement in January 1999, through the foundation’s early years as the JSF, to the RFCs and its 2007 renaming.