3 One idea, from proposal to published text

3.1 It starts with a work item

Nothing in 3GPP begins with writing text. It begins with permission to write it.

An Individual Member, or a group of them, proposes new work by submitting a Work Item Description sheet §6.1. No substantial work starts in a Working Group before the responsible Technical Specification Group (TSG) above it has decided §6.1.

The sheet has to carry a precise scope, an estimated schedule, a named rapporteur (the delegate who will carry the work), and at least four Member Organizations willing to do it §6.0.2.

3.2 From a blank page to a number

Once the work is authorised, one person holds the pen:

From there the version number tracks how finished the text is. At roughly 60% stability it is renumbered 1.0.0 and shown to the group above for information; at roughly 80% it becomes 2.0.0 and is put to that group for approval §4.0A, §4.1.1.

On approval the version jumps straight to x.0.0, where x is the Release. A document approved for Release 4 goes from 2.0.0 to 4.0.0; no 3.y.z ever exists §4.1.1.

3.3 Under change control

That jump changes how the document may be touched:

A Change Request is a formal proposal, on a standard form, to modify a specification under change control §2. Any individual member may raise one and bring it to the responsible group §4.6.1.

Its number comes from the 3GPP portal or the Support Team, and numbers are never reused, not even one that was turned down §4.6.1. Every Change Request carries a category: A for a mirror of an earlier Release, B for adding or removing a feature, C for changing one, D for editorial, F for a correction §4.6.2.

Then it travels: the Working Group agrees it, its secretary collates the agreed ones and sends them up, and the parent group approves them §4.6.1, §4.6.4.

On approval, the middle version number goes up and the last resets: 7.2.1 becomes 7.3.0 §4.1.1. The new text goes onto a file server that allows anonymous access to anyone §5.1.

Across the record: 1,629,581 meeting documents ^[2], 516,786 of them Change Requests ^[3].

3.4 What a Release is

Which Release a version belongs to is the first digit of x.y.z §4.0A. Releases are not annual, and are named after that digit — Release 4, Release 5, and so on §4.10.3.3. The catalogue holds 19 named releases ^[4].

Two rules keep the set consistent:

• New functionality only goes forward. It belongs in the latest Release that is not yet frozen, never back into a frozen one, because that would break interoperability between systems already built to it §4.10.3.2.

• Essential corrections go backwards. The same fix is made in every earlier Release that is not closed §4.10.3.1.

The second rule is why mirror Change Requests exist: one independently numbered Change Request per affected Release, decided together §4.10.2.

Frozen and closed are the two end states. Freezing allows only essential corrections §4.7; closing permits no changes of any kind, not even alignment with a later Release §4.8.

3.5 The same journey at the IETF

A specification under development is posted to the Internet-Drafts directory for informal review and comment RFC 2026. That is all it is:

To move it forward, the working group recommends it to its Area Director, and only after the draft has been public for at least two weeks. The IESG — the body of Area Directors that approves IETF standards ^[5] — then runs an IETF-wide Last Call by email, open to anyone, for at least two weeks, or four if no working group stood behind the document RFC 2026.

If it passes, the RFC Editor is told to publish it and the draft leaves the drafts directory RFC 2026. The entry level of the standards track is Proposed Standard ^[6], and a later document replaced the old three-tier ladder with two levels ^[7].

And then it stops moving. An RFC is never edited after publication: a new version goes through the entire process again as if it were new RFC 2026.

Next: how to follow any of this in the record yourself, in Looking it up yourself, and what the record will not tell you.