SMPTE   AG   02
Administrative Guideline

Document Naming and Packaging

Approved - Approved: 2025-03-25

Copyright © 2025 , Society of Motion Picture and Television Engineers . All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.

Table of contents 🔗

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 Language
  7. 6 Style and Form
    1. 6.1 Style Guidelines
    2. 6.2 Document editing
  8. 7 Publication Formats and Elements
    1. 7.1 Publication Formats Overview
    2. 7.2 File Formats for Document Submission
      1. 7.2.1 Main element
      2. 7.2.2 Additional elements
    3. 7.3 SMPTE HQ Guidance
  9. 8 Normative Language Forms
  10. 9 Dates
  11. 10 Document Numbering
    1. 10.1 Document Numbering Overview
    2. 10.2 Engineering Document Type
    3. 10.3 Parts
      1. 10.3.1 General
      2. 10.3.2 Parts of Different Types
      3. 10.3.3 Part 0 Documents
      4. 10.3.4 Normative References to Multipart Documents
    4. 10.4 Elements
    5. 10.5 Number Space
  12. 11 Work In Process File Naming Conventions
    1. 11.1 Due Process Engineering Documents
    2. 11.2 Elements That Are One File
    3. 11.3 Elements That Are a Collection of Many Files
    4. 11.4 File Names for Contributions
  13. 12 Document Packages
    1. 12.1 Document Packages Overview
    2. 12.2 Working Draft Development
    3. 12.3 Pre-Ballot Review Document Package
    4. 12.4 Final Committee Draft Ballot Document Package
    5. 12.5 FCD Ballot Comment Resolution Package
    6. 12.6 Pre-Draft Publication Vote Review Document Package
    7. 12.7 Draft Publication Vote Document Package
    8. 12.8 ST Audit Document Package
    9. 12.9 SMPTE HQ Editing Publication Document Package
  14. 13 Registered Disclosure Documents (Informative)
  15. Bibliography

Foreword 🔗

The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. For more information, please visit www.smpte.org .

This Standards Administrative Guideline forms an adjunct to the use and interpretation of the SMPTE Standards Operations Manual. In the event of a conflict, the Operations Manual shall prevail.

1 Scope 🔗

This Administrative Guideline defines the numbering format for SMPTE Engineering Documents and specifies the permitted file formats used during document development and publication. It also specifies other matters relating to SMPTE Engineering Documents with regard to language, style, format, document type, markups required at various stages of development, etc.

Files that show the differences between two versions of the same document are called "markups" in this Administrative Guideline. "Markup" is intended to cover a variety of terms including: "redline," "tracked changes," "blackline," etc.

2 Conformance 🔗

The following keywords have a specific meaning in the context of this document:

3 Normative references 🔗

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

4 Terms and definitions 🔗

No terms and definitions are listed in this document.

5 Language 🔗

All SMPTE Engineering documents shall be written in U. S. English. Translations into other languages by SMPTE (or by 3rd parties authorized by SMPTE) are encouraged but not required. In the event of discrepancy, the original English language document shall be authoritative.

6 Style and Form 🔗

6.1 Style Guidelines 🔗

All Engineering Documents should follow the guidelines of the ISO/IEC Directives, Part 2 with the following exceptions: In the event of a conflict, explicit provisions of SMPTE Standards Operations Manual and Administrative Guidelines shall prevail. Any variances from the ISO/IEC Directives, Part 2 shall be approved by the Director of Engineering or the Standards Vice President.

Particular attention should be given to the following annexes of the ISO/IEC Directives, Part 2 :

The ISO Directives are available at: http://www.iso.org/directives .

6.2 Document editing 🔗

All Engineering Documents shall use SMPTE AG-26 and SMPTE AG-27 as of 2025-06-01 .

Prior to being submitted for pre-FCD ballot review, draft Engineering Documents may use other editing formats, as selected by the Project Group.

For a revision of an Engineering Document, if not already published in HTML, the Publication Master can usually can be obtained from SMPTE HQ. The Project Group should recreate the original document, as closely as possible to published, in HTML format as per SMPTE AG-26 , prior to any revision work to be done. This will ensure the tooling can create a proper redline document during the balloting process.

NOTE 1 —⁠ Care should be given when updating the tooling from prior HTML published versions, as major changes in said tooling may have occured. However, such changes may be required, such as general boiler plate verbiage, template update, and/or validation tools.

NOTE 2 —⁠ Since the HTML pipeline has been introduced, amendments are no longer able to be generated, only full revisions. As such, amendments shall no longer be utilized.

7 Publication Formats and Elements 🔗

7.1 Publication Formats Overview 🔗

SMPTE Engineering Documents shall be published in HTML and may comprise one or more separate elements. An Engineering Document always shall include a single prose element and may include other elements such as XML, spreadsheets, media files, and so forth. The collection of elements, regardless of formats employed, is the "Engineering Document" as a whole, and all elements shall be clearly identified in the prose element (see 10.4 ). Any change to any element constitutes a change to the Engineering Document. The Project Group and the Technology Committee shall determine the number of elements for publication. The Director of Engineering shall determine the distribution media for all published documents. The format of publication shall alter neither the relevance of, nor the processes that otherwise are required for approval of, an Engineering Document.

Engineering Document Elements may be packaged as one or more Elements using ZIP to facilitate the organization and distribution of the component files.

7.2 File Formats for Document Submission 🔗

7.2.1 Main element 🔗

With the exception of figures, the main element shall be submitted as a single HTML document, as specified at SMPTE AG-26 .

Images referenced in the main element shall use one of the following formats:

An editable master shall be provided for each image in a format other than image/svg+xml . The editable master shall be in one of the following formats:

7.2.2 Additional elements 🔗

Additional elements may be provided in any format that is specified in a Permitted Normative References, as defined in SMPTE AG-03 , and for which a media type exists, as specified at IANA Media Types .

The file name extension for each additional element shall conform to the convention specified at IANA Media Types .

7.3 SMPTE HQ Guidance 🔗

The Director of Engineering shall store and process documents in the format chosen by a Project Group and/or Technology Committee. The Director of Engineering shall ensure that copies of the editable source documents are maintained for all published Engineering Documents. The editable publication master should be made available by the Director of Engineering when a Revision or Amendment project is started.

8 Normative Language Forms 🔗

Normative information in a SMPTE Engineering Document may take the language form of prose, tables, figures, formal languages (e.g., mathematical formulae, BNF, XML, pseudo code), and other language forms. Mathematical formulae shall follow the definitions documented in ISO 80000-2 when possible. When ISO 80000-2 is not sufficient (e.g., BNF, XML Schema, etc.), a Normative Reference for the mathematical definitions used shall be provided. Such Normative Reference shall comply with the provisions of the SMPTE Standards Operations Manual and SMPTE AG-03 .

When language forms other than prose are present, the prose shall state whether the language is normative or informative. Normative provisions shall be enabled explicitly (e.g., "The dimensions of figure 1 shall be used."). The presence of non-prose information without prose conformance language shall be deemed informative.

9 Dates 🔗

In accordance with ISO 8601 , all dates shall be represented in the form YYYY-MM-DD as numeric digits (e.g. 2009-04-23 to indicate April 23, 2009).

10 Document Numbering 🔗

10.1 Document Numbering Overview 🔗

Document numbers shall be unique and uniform across all Engineering Document types. Versions of documents shall be identified by the year and month of their approval date, appended with a separating colon (e.g., for document #1020: 1020:2009-04 indicating approval in April, 2009). Figure 1 shows an example of the document numbering structure. The approval date of a document indicates when it was last approved by its consensus body, e.g., Technical Committee.

The Director of Engineering shall assign document numbers (or root document numbers, in the case of multipart documents). Document numbers may be assigned at the request of the Technology Committee Chair(s) at any time after a Project is approved and shall be assigned before a Final Committee Draft ballot is issued.

Older Engineering Documents may bear one-, two-, or three-digit document numbers or root document numbers. These numbers shall not be prepended with leading zeroes when formatted for printing, either in the document itself or in citations in other documents. Such document numbers shall be prepended with leading zeroes to fill them out to four digits, however, when used as part of an element’s filename; the purpose is to facilitate sorting into numerical order.

Figure 1 –⁠ Example Document Number

10.2 Engineering Document Type 🔗

The Type of Engineering Document (Standard, Recommended Practice or Engineering Guideline) shall be denoted by prepending a Type Designator, followed by a single space, to the document’s root number. The Type Designator shall be as follows:

ST
Standard
RP
Recommended Practice
EG
Engineering Guideline

Although they are not Engineering Documents, Registered Disclosure Documents, Advisory Notes, Administrative Guidelines, and Engineering Reports shall bear Type Designators as follows:

RDD
Registered Disclosure Document
AN
Advisory Note
AG
Administrative Guideline
ER
Engineering Report
OV
Overview Document (Part 0 document)

RDDs and ERs shall be numbered using independent number spaces. The numbers shall be assigned by SMPTE Headquarters staff.

10.3 Parts 🔗

10.3.1 General 🔗

Closely related Engineering Documents may be created as Parts. A Part of a document is a separate Engineering Document and shall be shown to be related to other by using the same root document number plus a suffix of a hyphen and the Part number to distinguish among Parts (e.g. 1020-2:2009-04 , indicating document 1020, Part 2).

10.3.2 Parts of Different Types 🔗

A multipart set of documents may include Parts of different types of Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines. Each Part’s number shall include the appropriate document type designation (e.g. RP 2046-2:2009-04 ).

10.3.3 Part 0 Documents 🔗

A multipart set of documents should be supplemented by an informative Part 0, informally described as an “Overview Document,” which shall describe the relationships among the Parts and may describe the relationships of the Parts to other Engineering Documents. Part 0 documents are not due process Engineering Documents;

Part 0 documents usually should be prepared by the authors of the related engineering documents in cooperation with SMPTE headquarters staff and the responsible Technology Committee and Project Group. Part 0 documents shall be maintained by the Director of Engineering in consultation with the Technology Committee Chair(s) and the author(s) of the Part 0 document. If new Parts are added to a multipart set, or if any of the Parts of the set are revised, Part 0 shall be revised at the same time. The Part 0 designation shall not be used for any Engineering Document. Part 0 documents shall not bear a Type designator (i.e. it is not an ST, RP or EG).

A Part 0 document should not contain forward-looking statements in regard to documents that are not ready for publication.

As a general guideline, Part 0 documents should use the following structure:

  1. an overview of the general application of the related engineering documents, in a language that can be understood by non-experts
  2. an overview of the scope of various related documents, with graphical representations, if appropriate
  3. an overview of the contextual relationships of various engineering documents

Examples of Part 0 documents: SMPTE 2052-0 or SMPTE 425-0.

10.3.4 Normative References to Multipart Documents 🔗

Normative references to multipart documents always shall specify the individual Part or Parts being referenced and shall not reference the entire set by root number alone.

10.4 Elements 🔗

Non-prose Elements of Engineering Documents (see Clause 7 ) shall be designated using a lower case letter (e.g. 1020a:2009-04 and 1020b:2009-04 ). Media such as DVDs, as well as non-PDF formats, shall be clearly marked, as appropriate. The single prose element shall not receive aletter suffix.

10.5 Number Space 🔗

All new Engineering Documents shall share a common root number space, starting with 2000, except for new Parts of multipart documents that have a one-, two- or three-digit root.

In the past, each type of Engineering Document had its own number space. This presented difficulties when a Technology Committee determined that the document type had to be changed (for example, changing a Recommended Practice to a Standard) if the number in the new number space already was in use. To address this going forward, the block of numbers from 1000 to 1999 has been allocated.

If a Technology Committee determines that the classification of an Engineering Document with a one-, two- or three-digit root must be changed (e.g., from a Recommended Practice to a Standard) and there already is an Engineering Document with that number, the document whose classification is being changed shall have 1000 added to its root. For example, if the Technology Committee were to determine that Recommended Practice RP 222 should be changed to a Standard, its number would be changed to SMPTE ST 1222 because there already is a SMPTE ST 222.

Each of the other published document types (i.e., Registered Disclosure Documents, Advisory Notes, Administrative Guidelines, and Engineering Reports) shall have its own number space independent of Engineering Documents and of each other. They otherwise shall follow the rules for document numbering specified in this Administrative Guideline.

11 Work In Process File Naming Conventions 🔗

11.1 Due Process Engineering Documents 🔗

File names for due process Engineering Documents should be constructed as follows. 

<group> “-“ <state> “-“ <type> “-“ <number> [ “-“ <part> ] [ <element> ] “-“
  <description> “-“ <date> [ “(“ <note> “)” ] “.” <extension>

Where:

<group>
is the Group that authored the document (e.g., TC name, “31FS”)
<state>
is “WD” | “CD” | “FCD” | “DP”
<type>
is “ST” | “RP” | “EG” | “RDD” | “AN” | “ER” | “OV” | “AG” See 10.2
<number>
is the SMPTE HQ staff-assigned document number
<part>
is the optional part number
<element>
is the optional element letter
<description>
is a brief indicator of subject, such as an abbreviated name of the document, which is constructed using only alpha characters, digits and "-". The description is a required element of the file name.
<date>
is the document version date, formatted (“YYYY-MM-DD”) as defined in Clause 9 .
<note>
is an optional string that can be used to annotate the file contents, e.g., “(clean),” “(markup),” “(package),” or similar information. The <note> shall be constructed using only alpha characters, digits, “-“.
<extension>
is an approved extension. See 7.2

NOTE —⁠ The <description> and <note> fields can use CamelCase or hyphens as word separators. The Document Editor and Project Chair need to consider both choices and make a decision based on the project name, any acronyms used, the length of the name and related factors.

11.2 Elements That Are One File 🔗

The Project Group should follow the recommendation in this section or the requirements in Clause 10 . The final publication name shall be assigned by the Director of Engineering.

11.3 Elements That Are a Collection of Many Files 🔗

Elements that are a collection of files shall be aggregated into a single file that is a .zip file. The .zip file may contain other .zip files if necessary. The file name for the .zip file shall follow the rules outlined in 11.2 . The names of the files in the .zip file shall be at the discretion of the Project Group. The Project Group may use the schemes defined in this AG. They should use a scheme that is appropriate for the files in the element.

11.4 File Names for Contributions 🔗

File names for contributions that are not Engineering Documents shall be at the discretion of the individual or group making the contribution. The scheme in 11.1 should be considered as a useful model. If these rules are used, the <state> should be “C.”

For a new project, the document number and even the project short name may not be known. In this event, individuals making the contributions should use their judgment when naming files.

12 Document Packages 🔗

12.1 Document Packages Overview 🔗

Various document packages are needed during the development process. In all cases, a document being reviewed or voted upon shall be the current draft which is the “clean” version, generated in zip file within the GitHub release as described in SMPTE AG-26 . All the below described packages are auto-generated by this tooling and shall not be created by hand.

In the event that any of the following is in conflict with the SMPTE Standards Operations Manual , the SMPTE Standards Operations Manual shall prevail.

12.2 Working Draft Development 🔗

Clause 6 of this AG has guidance for the use of templates for new projects and Revisions.

For Revisions the process of converting an old document into the current template changes section numbering and alters the appearance of the original document, even though the content of the document has not changed. In this case, it is recommended that the conversion to the current template should be made before any other changes are made. The document editor should “accept all changes” to create a clean starting point (the “baseline draft”) from which to track the technical and/or editorial revisions to the document.

During Working Draft development (an informal process), a Project Group may provide intermediate draft documents and markups for review within the Project Group. Intermediate document packages may include an informal Comment Resolution Record or a Comment Resolution Document.

The state of these draft documents shall be “WD.” Project Groups should follow the recommendations and styles given in this Administrative Guideline for file names.

12.3 Pre-Ballot Review Document Package 🔗

The first step in the formal document process is the preparation of a Working Draft, which shall be marked as “WD.” This document a package is provided by the Project Group to the Technology Committee Chair(s). This review is optional; See SMPTE Standards Operations Manual for guidance.

The document package shall contain a clean draft. In addition it may contain one of the following:

12.4 Final Committee Draft Ballot Document Package 🔗

Following Pre-Ballot Review, a Project Group should address all comments. See the comment resolution process in SMPTE Standards Operations Manual . When the Project Group agrees that the document is ready for ballot, it shall provide a Committee Draft ballot package marked as “CD” to the Technology Committee Chairs(s) that contains:

When additional Final Committee Draft Ballot(s) are required, the Project Group shall submit a package to the Technology Committee Chair(s) that contains the following:

A Comment Resolution Record is required when there are additional FCD Ballot(s). This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See SMPTE Standards Operations Manual for guidance.

12.5 FCD Ballot Comment Resolution Package 🔗

NOTE —⁠ If a document passes Final Committee Draft ballot with no comments, comment resolution, Pre-DP Review and a Draft Publication Vote are not required. See SMPTE Standards Operations Manual for guidance.

Incremental Comment Resolution within the Project Group may result in the need for multiple Drafts, Markups, and Comment Resolution Records or Comment Resolution Documents. These document packages shall contain:

A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See SMPTE Standards Operations Manual for guidance.

When Comment Resolution has been successfully completed, a Pre-DP Review follows. Comment resolution may include one or more Disposition Votes. See SMPTE Standards Operations Manual for guidance.

12.6 Pre-Draft Publication Vote Review Document Package 🔗

Following comment resolution, the Project Group shall provide the Technology Committee Chair(s) a Pre-DP review package that contains:

A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See SMPTE Standards Operations Manual for guidance.

12.7 Draft Publication Vote Document Package 🔗

Following the Pre-DP Review, the Project Group shall provide the Technology Committee Chair(s) a DP Vote package that contains:

A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See SMPTE Standards Operations Manual for guidance.

After a successful DP vote the Draft Publication Vote Package documents shall not be edited by the Project Group participants or the Technology Committee Chair(s) with the exception of changing the document status. If new editorial issues are found, these should be documented and given to SMPTE HQ (see 12.9 ).

12.8 ST Audit Document Package 🔗

This document package is the responsibility of the Technology Committee Chair(s) and shall contain:

A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. If the Project Group kept other records, these must be included. See SMPTE Standards Operations Manual for guidance.

12.9 SMPTE HQ Editing Publication Document Package 🔗

The Technology Committee Chair(s) shall provide a document package to SMPTE HQ that includes:

NOTE —⁠ After each document achieves a successful ST Audit, SMPTE staff will prepare it for publication. The Technology Committee Chairs(s), Project Group Chairs(s) and Document Editor(s) who are responsible for the document are expected to review and approve it before publication.

13 Registered Disclosure Documents (Informative) 🔗

Registered Disclosure Documents (RDDs) are not Engineering Documents. The RDD approval process includes a Technology Committee Ballot, Comment Resolution and an ST Audit.

Using the content and form of the appropriate Engineering Document packages is recommended.

Bibliography 🔗