1 Why anybody writes a standard down

1.1 What breaks when nobody writes it down

Two engineers can agree a protocol over lunch. Two hundred companies, across four continents, building parts that will meet for the first time in a customer's hand, cannot.

The pieces are made separately, by people who will never speak, on schedules that do not line up. The only thing that makes them fit is a description everybody had in front of them before they started building.

That is all a standard is: a description with a name, written in advance, that says how a particular thing is done. The IETF puts it exactly that way — the description does not oblige anybody to use it, and the benefit of it is that products built from it work together RFC 3935.

The failure is easy to picture and hard to repair. Two makers read the same loose description, each fills the gap it leaves in a reasonable way, and the two results do not talk to each other. Nothing is broken in either product; they simply disagree.

3GPP names that failure directly when it forbids putting new functionality back into an older, frozen Release: doing so would cause incompatibility among systems built to that Release §4.10.3.2. The whole point of holding the line, the document says, is roaming that works across separately built networks §4.10.3.

1.2 What each body says it is for

The IETF states its purpose in a single sentence, and then spends the rest of the document unpacking it.

The same document names five principles the work runs on: an open process, technical competence, a volunteer core, rough consensus and running code, and protocol ownership RFC 3935. The fourth of them, rough consensus and running code, comes back later in this course as machinery, not as a slogan.

3GPP gives a more industrial reason, and it is worth reading twice, because it explains almost everything odd about the way 3GPP works.

Products are being built while the text is still moving. So the text cannot move casually. Every change has to be proposed on a form, decided in a meeting, and recorded — which is what the whole of The Change Request, field by field is about.

The document gives a second reason in the next breath: changes must be well documented and controlled, so that technical consistency and backwards tracing are kept intact §Introduction. Backwards tracing means you can ask of any sentence in a live specification: when did this arrive, and who decided it?

1.3 Nobody is obliged to obey either of them

This surprises people. Neither body has the power to make anybody do anything.

A 3GPP document by itself imposes no obligation. An obligation arrives from somewhere else — legislation, or a contract between two companies — and the document is what that obligation points at. That is precisely why the drafting rules are so strict about which verb makes a sentence a requirement and which verb makes it a recommendation ^[2]. If the reader cannot tell the two apart, the contract that points at the document means nothing. Why the documents read the way they do takes that apart word by word.

3GPP is not even a legal entity in its own right. The clearest evidence sits in an unglamorous corner of the working methods, where the document explains who signs for a registered code point.

Which organisations those partners are, this course cannot tell you. TR 21.900 mentions the Organizational Partners twice, and the meeting calendar on this machine records that they hold meetings 3GPP OP, but no file read for this course lists them by name. The place to look is the 3GPP Working Procedures ^[3], the rulebook one level above the working methods.

1.4 What the working-methods document actually covers

TR 21.900 is a short document about how the other several thousand are handled. It has 97 clauses ^[4]. Its scope names document management, updating procedures, Change Request procedures, version control and status information §1.

It also says what it leaves alone, and that sentence saves a reader a great deal of searching: it does not stipulate the details of the internal working of the sub-groups §1. Each group sets much of its own routine. What is written down is the part where a group has to hand something upwards.

The reference list is short enough to read in full §1A, and it is a map of where the rest of the rules live:

• TR 21.801, the drafting rules — how a document is worded and which verbs are permitted TR 21.801 v19.1.0.

• TR 21.905, the vocabulary — 579 terms every other 3GPP document borrows TR 21.905 v19.2.0, ^[5].

• TS 21.101 and TS 41.101, the lists of which specifications you need to build a particular kind of system TS 21.101 v19.0.0.

• ITU-T Recommendation I.130, the source of the three-stage method that splits requirements from architecture from protocol.

• TS 29.501, for the service-interface files that ride along with modern stage 3 documents.

• IETF RFC 3629, the definition of UTF-8 RFC 3629 — the one place where 3GPP's rulebook reaches out and stands on an IETF standard.

• The 3GPP Working Procedures, which is where the partnership's own constitution lives ^[3].

1.5 How much of it there is

Both bodies have been producing text for decades, and the volume is part of what the machinery exists to manage.

What	How many
3GPP specifications in the catalogue	3,928 [6]
of them Technical Specifications	2,149 [7]
of them Technical Reports	1,778 [8]
still maintained	3,599 [9]
no longer maintained	329 [10]
RFCs in the local archive	9,735 [11]

Underneath the specifications sits the paperwork that produced them. The calendar holds 4,371 3GPP meetings ^[12], and those meetings have left 1,629,581 documents behind them ^[13]. Change requests alone account for 516,786 of that pile ^[14].

1.6 Where this leads

The rest of the course follows the machinery in the order a piece of work meets it. First the bodies that hold the meetings, in The shape of 3GPP, and what the record does not say about it. Then the container the work is packed into, in What a Release is, and what freezing one costs. Then the life of a single document, in The life of a 3GPP document, from blank page to published version.

The IETF half starts at The shape of the IETF, and the two are set side by side in The two cultures, side by side and on the evidence.