School of Specs How standards actually get madeOverview

Why any of this exists · chapter 1 of 7 · 6 minutes

1 Why anybody writes a standard down

The problem a standard solves, the reasons 3GPP and the IETF each give for their own rules, and why neither body can oblige anyone to do anything.

Built from §Introduction §3.2 §5.1 §6.0.2 §6.1 §9.2

1.1 The problem a standard solves

A phone bought in one country has to work on a network in another, on radio equipment built by a third company and core software built by a fourth. Nobody owns that whole chain, and no company can fix it by shipping a better product.

What makes it work is that everybody wrote down, in advance and in public, where one piece stops and the next one starts. A standards body is the place where that writing happens, and the set of rules under which it happens.

Two of them are worth knowing side by side. 3GPP writes the mobile network. The IETF writes the Internet. They want much the same thing and go about it in almost opposite ways.

1.2 3GPP's reason, in its own document

3GPP keeps its own working rules in a document of 97 clauses, and this course is built on it [3]. Its opening pages say why the rules have to be strict §Introduction.

That is the whole of it. Nobody waits for the document to be finished before building from it, so a change agreed in a meeting lands in somebody's product plan the same month.

If the record of what changed, when and why is sloppy, two companies end up building to two different readings of the same page, and the phone from one does not talk to the network from the other.

The same page names the machinery that follows from this: version control, change control, document updating, distribution and management. Those five words are the outline of the next three chapters §Introduction.

It also draws a line that runs through everything else. The groups and their sub-groups, together with the Support Team, are responsible for the technical content and its consistency. The Support Team alone is responsible for managing the documentation — the specifications, the meeting documents, the administrative record and the exchanges with other bodies §Introduction.

So the delegates own what the document says. The permanent staff own the document.

1.3 The IETF's reason, in one sentence

The same document names five principles the body works by: an open process, technical competence, a volunteer core, rough consensus and running code, and protocol ownership RFC 3935.

It is also unusually blunt about what a standard is: a description carrying a unique name that says, if you want to do this thing, this is how it is done. It obliges nobody. The payoff is only that products built from it work together RFC 3935.

1.4 Neither body can make you do anything

3GPP's legal shape shows through in a small, telling place. Now and then a number has to be registered with an outside body, and the document says the Support Team does the registering, in the name of one of the Organizational Partners, on behalf of all of them, because 3GPP itself is not a legally constituted entity §3.2.

The working-methods document mentions those partners without ever listing them, and no file read for this course names one. If you want to know who they are, that answer is somewhere else.

1.5 Who takes part

Here the two bodies split hard.

3GPP's rules talk about members as organisations: a work item is proposed by an Individual Member of 3GPP or a group of them §6.1, and the work only starts with at least four Member Organizations willing to do it §6.0.2.

The IETF says the opposite in two sentences.

Nothing read for this course says how many people attend either body, what membership costs, or who chairs anything. Those are real questions with real answers; they are simply not in this material.

1.6 What a standards body has to have

Strip both bodies down and the same three parts are left, whatever they are called locally.

R1. A way of turning a proposal into text. In 3GPP that is the work item and the change request. In the IETF it is the Internet-Draft and the RFC.

R2. A way of deciding. 3GPP names two bodies and records a verdict against every document §9.2. The IETF refuses to vote and asks a chair to judge whether objections have been answered RFC 7282.

R3. A record anybody can go back to. 3GPP puts approved versions on a server open to any interested party §5.1. The IETF publishes an RFC and then never edits it RFC 2026.

The rest of this course is those three parts, twice over.

1.7 How much of it there is

The counts give a sense of scale without pretending to be a judgement.

What is counted How many
3GPP specifications in the catalogue 3,928 [5]
— of those, Technical Specifications 2,149 [6]
— of those, Technical Reports 1,778 [7]
RFCs in the archive on this machine 9,735 [8]

A specification tells you what to build; a report records a study. Both are called "specifications" in the working-methods document, which is a small trap covered in The shape of 3GPP, and where the data stops.

One more honest note before the machinery. These numbers count output. Nothing in them supports a sentence saying one of these bodies is faster, better run or more open than the other, and this course does not contain such a sentence.

Where the numbers in this chapter come from

  1. RFC 3935, section 1 the words of section 1 of RFC 3935 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc3935.txt
  2. RFC 2418, section 1 the words of section 1 of RFC 2418 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2418.txt
  3. 97 clauses in TR 21.900, the working-methods document parsed clause files of 3GPP TR 21.900 v20.0.0, counted in /var/www/whatthespec.net/data/friendlyspec/json/21900/20.0.0/sections on 2026-08-04
  4. TR 21.801, Annex E the words of clause Annex E of 3GPP TR 21.801 v19.1.0 as parsed under /var/www/whatthespec.net/data/friendlyspec/json/21801/19.1.0
  5. 3,928 3GPP specifications in the catalogue rows in table `spec` of the pygppe specification catalogue, read from /var/www/whatthespec.net/data/database/api/spec_catalog.sqlite on 2026-08-04
  6. 2,149 of them are Technical Specifications rows in table `spec` where type='TS', read from /var/www/whatthespec.net/data/database/api/spec_catalog.sqlite on 2026-08-04
  7. 1,778 of them are Technical Reports rows in table `spec` where type='TR', read from /var/www/whatthespec.net/data/database/api/spec_catalog.sqlite on 2026-08-04
  8. 9,735 RFCs in the local archive files named rfc<number>.txt or rfc<number>.xml, counted in /var/www/whatthespec.net/data/data/rfcs on 2026-08-04

Every source this course is built on

Check yourself

Answers appear when you pick one, with where they come from.

Q1.1 What reason does 3GPP's working-methods document give for needing strict and fast procedures?

Q1.2 How does the IETF state its goal?

Q1.3 Why does the 3GPP Support Team register code points with outside bodies rather than a delegate doing it?

Q1.4 A vendor says "this is a standard, so we are legally required to do it". What is wrong with that?

Q1.5 Roughly how much material do the two bodies have on this machine?

This chapter was written against TR 21.900 version 20.0.0, and built from a source register generated 2026-08-04. A newer version of the document may say something else.