4 The life of a 3GPP document, from blank page to published version

4.1 Why the state of a document has to be visible

At any moment a few thousand 3GPP documents are in different conditions. Some are private sketches. Some are stable enough to build against. Some may not be touched except to fix a serious error.

An engineer picking one up has to know which, and has to know it from the document itself rather than by asking somebody. That is what this whole procedure is for: the version number on the cover is a status report.

4.2 Before anything is written: the three stages

Where it fits, the work follows the three-stage method borrowed from ITU-T Recommendation I.130 §4.1:

• Stage 1 is an overall service description from the user's standpoint.

• Stage 2 is an overall description of how the network's functions are organised to map those service requirements into network capabilities.

• Stage 3 is the definition of the switching and signalling needed to support what stage 1 asked for.

The document adds two informal bookends. A feasibility study before formal specification work is sometimes called "stage 0", and the test specifications that follow stage 3 are sometimes called a stage 4 §4.1.

This matters when reading any 3GPP document, because it tells you what kind of answer that document is allowed to give. A stage 2 document that appears to define a message is being read wrongly.

4.3 Creation, and the draft years

A new specification is created in a group, and the first act is to appoint the person who will write it.

The pattern of those numbers is a working rule, not decoration. Versions 0.1.0, 0.2.0, 0.3.0 and so on should be presented to the responsible group; versions 0.i.1, 0.i.2 and so on may stay internal to the drafting group §4.1.1. Every draft that increments the middle digit goes in front of the group.

Two or more groups may have an interest, but responsibility rests with exactly one of them, and that group has to give the others the chance to take part. Where a second group has objectives of its own, they are written into the Work Item Description, naming additional rapporteurs if needed §4.1.1.

The number on the cover arrives separately. The Support Team allocates specification numbers, and does so as soon as the title, scope and a little other information are stable; the document then goes into the Status List of Specifications, and the responsible sub-group tells its parent TSG that a new specification is under construction §4.1.1, §7.1.

During all of this the document is a draft: internal to the TSG, changeable without formal Change Requests §2, §4.3.

4.4 Gate one: presentation for information

When the responsible group judges the draft stable enough, the Support Team converts the latest 0.y.z to version 1.0.0 with no technical change, and it is presented to the plenary for information §4.1.1.

The guideline is that a document reaching 1.y.z is estimated at least 60% stable, and the document is candid that this is subjective and ultimately the responsible group's decision §4.0A. What is not optional is the number: a document reaching that point and going to the plenary for the first time shall carry major version 1 §4.0A.

Further 1.y.z drafts may follow. Until formal approval, the document is under the control of the responsible sub-group, which decides case by case how changes are introduced §4.1.1.

4.5 Gate two: presentation for approval

When the group thinks it is time to put the document under change control, the latest 1.y.z becomes version 2.0.0 — again with no technical change — and is put to the plenary for approval §4.1.1. The stability guideline for this step is roughly 80% §4.0A.

Two outcomes, both written down:

• Refused. Further drafts numbered 2.y.z may be produced by the responsible group, and the document tries again §4.1.1.

• Approved. The version jumps.

The note underneath is the one every newcomer needs: it is quite normal for a specification approved for Release 4 to jump straight from 2.0.0 to 4.0.0, since there is no Release 1999 document and therefore no 3.y.z §4.1.1.

4.6 After approval: a different regime, and a different editor

From the moment version x.0.0 exists, the document is under change control, and any technical change from that point on is made by Change Request §4.6.1.

The editing pen changes hands at the same moment. Up to change control the rapporteur serves as editor, following the Working Group's guidance, and hands a clean document to the Support Team for editorial tidying before the approval step §4.1.2. Afterwards, the Support Team person responsible for the specification edits it to incorporate the approved changes §4.6.1.

The rapporteur does not disappear. In co-operation with the Support Team, the role is to review every Change Request before the Working Group agrees it — including spotting and resolving clashes between them — to oversee technical quality, to explain the document to any other group inside or outside 3GPP, and to be the point of contact for technical questions §4.1.2.

A new version is issued when there is at least one approved Change Request against the document; the Support Team then produces and issues it §4.6.5.

4.7 What the states are called

Two clauses give the vocabulary. Clause 4.3 describes the states a major version can be in §4.3:

• major version 0, 1 or 2 is a draft or withdrawn, and is TSG internal;

• major version above 2 is under Working Group change control, or under TSG change control, or closed, or withdrawn — and is either authorised for publication or TSG internal;

• a major version under TSG change control is either frozen or not yet frozen.

Clause 4.4 then does the same at the level of an individual version, spelling out for each shape of version number what must already have happened to the document §4.4. It is the clause to open when somebody hands you a version number and asks what it implies.

4.8 Available is not published

The Support Team makes every approved version available as soon as possible after approval, on a file server that allows anonymous access to any interested party — and should also try to make earlier drafts available, including 0.y.z, 1.y.z and 2.y.z versions §5.1.

That is availability. Publication is a separate act performed by somebody else.

Under the partnership agreement, the Organizational Partners that are standards development organisations publish the approved specifications as their own standards, by their own rules, and how they do it is outside the scope of the working methods §5.1. This course cannot name those partners ^[1].

The file server's structure is prescribed too: it separates approved from draft, versions approved at particular meetings, versions belonging to different Releases, and second-generation from third-generation material, with a guide to the structure and a status list showing the latest version of each Release of each document §5.1.

For stage 3 files that are code rather than prose — service-interface definitions, data models — there are two permitted arrangements, and which one applies is decided by the responsible Working Group §5.2, §5B, §5C.

4.9 Where this leads

The document is alive and under change control. Everything that happens to it from here arrives on one form, which is The Change Request, field by field. What authorised the work in the first place is Work Items and Study Items — how the work is authorised, and the version number it now carries is read digit by digit in Reading a 3GPP number — the series, the version, the file name.