A new specification shall be created in a Group. At creation, a rapporteur shall be appointed. The rapporteur shall produce an initial draft, version 0.0.0, and subsequent revised versions (version 0.1.0, possibly 0.1.1, 0.1.2 and so on, then version 0.2.0 etc.). Details of the role of the rapporteur are described in clause 4.1.2. The rules for drafting specifications, and the software tools to be used are listed in TR 21.801. Versions 0.1.0, 0.2.0, 0.3.0 etc. should be presented to the responsible Group. Versions 0.i.1, 0.i.2 etc. may be internal to the drafting group. Further drafts may be produced, with appropriate increments in the "technical" / "editorial" fields of the version number. Every new draft with an incremented "technical" version field shall be presented to the responsible Group. Although two or more Groups may have an interest in contributing to the development of a specification, ultimate responsibility vests in a single (responsible) Group. The responsible Group shall ensure that all other Groups which might have an interest are given the opportunity to participate in the drafting. The objectives intended to be provided or decided by a working group with secondary responsibility shall be made clear in a corresponding Work Item Description document, identifying additional rapporteurs from such secondary group(s) if necessary. The Support Team is responsible for allocating specification numbers. As soon as title, scope and some other information on the specification is stable, the Support Team shall assign a specification number according to the provisions of clause 4.0 and shall enter the specification into the Status List of Specifications (see clause 7). The TSG Sub-Group responsible for the specification shall inform its parent TSG that such a new specification is under construction. When a specification is sufficiently stable (see Table 3), it shall be converted to version 1.0.0 (with no technical changes with respect to the previous version 0.y.z) by the Support Team, and presented to the TSG for information. Further drafts bearing version numbers 1.y.z may be produced until the specification is sufficiently stable to be approved by the TSG. At this stage, and until formal approval by the TSG, the specification is, unless it belongs directly to a TSG, under the control of the responsible TSG Sub-Group. The modalities governing the introduction of changes shall be decided on a case by case basis by the WG concerned. Once the responsible Group considers that the draft is sufficiently stable (see Table 3) that it is desirable to place it under change control, the latest version 1.y.z shall be converted to version 2.0.0 (with no technical changes with respect to the previous version 1.y.z) by the Support Team and presented for approval at the TSG. If the TSG does not approve the draft, further drafts version 2.y.z may be produced by the responsible Group. If the TSG does approve the draft, the approved version (with no technical changes) shall be converted to version x.0.0 where "x" corresponds to the Release identity given in Table 4. The specification shall now be under TSG change control. Further changes shall be made by means of formal Change Requests, to be approved by the TSG. On approval of a CR, the middle number shall be incremented and the right-most number reset to 0 (e.g., from 7.2.1 to 7.3.0).

The role of the rapporteur is to:

• Serve as Editor (following the guidance of the WG) until the specification is placed under change control.
• Deliver a clean specification to the MCC for editorial clean-up before submission for TSG approval to come under change control.

and, in co-operation with MCC, to:

• Review all CRs to the specification prior to agreement in the Working Group. This includes identifying and resolving clashes.
• Oversee the technical quality of the specification.
• Explain the specification to any other group (WG, TSG, inside or outside 3GPP), where appropriate.
• Serve as focal point for technical questions.