15 Reading either body's paper trail from a cold start

15.1 The question this chapter answers

Somebody puts a sentence from a specification in front of you and asks why it says that. Or a supplier claims a behaviour is required and you want to know whether it is.

Both questions are answerable from public records, and neither needs anybody's permission. What they need is knowing which record holds which fact.

15.2 Reading a 3GPP document cold

• K1. Read the number. TS aa.bbb or TR aa.bbb. The first field gives the subject area, and the second tells you, for a report, whether it was ever meant for publication — aa.8bb reports are internal working documents, aa.9bb are intended for publication §4.0.

• K2. Read the version. Three digits. Below 3 in the first position it is a draft, and 1 or 2 tells you which gate it is at. From 3 upwards the first digit is the Release, the second counts technical changes and the third editorial ones §4.0A, §Foreword.

• K3. Read the file name if that is all you have. aabbb-xyz.eee packs both numbers, with the version characters in base 36 — and a d where the hyphen should be marks a draft that should never have left the group's own directory §5A.

• K4. Go to the change history annex. Every specification ends with one.

TR 21.900's own §Annex A is a working example: rows carrying the meeting, the document number the change travelled in, the change request number, its revision, its category letter, a subject line and the version it produced.

• K5. Take the change request number to the database. The change request database on the 3GPP file server records every change request ever raised, all its revisions included §4.6.1, §7.3, ^[1].

• K6. Or take the meeting to the portal. The portal will show the change requests of one specification or one meeting, with the decision reached on each §4.6.2, ^[2].

At the end of that route you have the category letter, which tells you what kind of change it was; the work item code, which tells you what authorised it; and the meeting, which tells you when it was decided and by whom The Change Request, field by field.

Two shortcuts are worth knowing. If the sentence you are chasing is a correction, its category will be F and the reason field on the form has to say what went wrong and what happens if the fix is refused §4.6.2. And if the change appears in several Releases at once with different numbers, you are looking at a family of mirror change requests decided together, not at four separate decisions §4.10.2.

15.3 The registers behind that route

Clause 7 lists what the Support Team keeps, and it is worth knowing all of it exists §7:

• the Status List of Specifications — every specification with its number, title, latest version and rapporteur, annexed to every SA meeting report §7.1;

• the Work Item Status List — every work item, with its planned documents, completion dates, milestones and responsible groups §7.2;

• the change request database — every change request to every specification §7.3;

• the membership databases — the delegates in the TSGs §7.4;

• the permitted tools, which are the ones named in the drafting rules §7.5;

• the website and file server — meeting calendars, minutes, documents and the latest specifications, with file server links per group reachable from the web pages §7.6, ^[3];

• the email lists — one per group, plus further lists per topic §7.7.

If you are filling in a form rather than reading one, 3GPP publishes its own step-by-step guidance for the change request cover page ^[4].

15.4 Reading an RFC cold

The route is shorter, because there is less machinery and no history inside the document.

• J1. Read the header block. It gives the category, the stream the document came from, its BCP or STD number if it has one, and what it obsoletes or updates RFC 7841. That is four facts before the first paragraph.

• J2. Decide whether it is a standard at all. Standards track, Best Current Practice, Informational, Experimental and Historic all share the same numbered series RFC 2026. Only the first is a standard, and even there Proposed Standard and Internet Standard are different things ^[5].

• J3. Follow "obsoletes" and "updates" forwards. Since a published RFC is never edited RFC 2026, anything that has happened to it since is a different document with a different number. A document with no successor is current; one with a successor may be Historic.

• J4. Check whether it imported the requirement words. If it cites RFC 2119 and RFC 8174, capitalised keywords bind as defined; if it does not, they are ordinary prose RFC 2119, ^[6].

Beyond the document itself, the current list of working groups and areas lives on the IETF website rather than in any RFC, because it changes ^[7].

15.5 Reading this course's own evidence

Everything in these chapters points at something you can open, and there are exactly three ways it does so:

• a clause link, such as §4.6.1, which opens the real text of that clause of TR 21.900 beside the chapter;

• a source link, such as RFC 2026, which points at an entry in the register behind this course;

• a counted number, such as the 3,599 specifications still maintained ^[8] or the 1,629,581 meeting documents on record ^[9]. Each one carries the exact query that produced it and the day it was asked, so you can ask the same question again rather than take the figure on trust.

TR 21.900 itself can be read clause by clause on this machine's own viewer ^[10], and the register page of this course lists every source it cites.

15.6 Where this leads

One chapter left, and it is the honest one: every question a reader would reasonably ask that the material behind this course cannot answer, collected in What this record cannot tell you.