draft-ietf-cellar-ebml-15.txt   draft-ietf-cellar-ebml-16.txt 
cellar S. Lhomme cellar S. Lhomme
Internet-Draft Internet-Draft
Intended status: Standards Track D. Rice Intended status: Standards Track D. Rice
Expires: 18 June 2020 Expires: 24 June 2020
M. Bunkus M. Bunkus
16 December 2019 22 December 2019
Extensible Binary Meta Language Extensible Binary Meta Language
draft-ietf-cellar-ebml-15 draft-ietf-cellar-ebml-16
Abstract Abstract
This document defines the Extensible Binary Meta Language (EBML) This document defines the Extensible Binary Meta Language (EBML)
format as a generalized file format for any type of data in a format as a binary container format designed for audio/video storage.
hierarchical form. EBML is designed as a binary equivalent to XML EBML is designed as a binary equivalent to XML and uses a storage-
and uses a storage-efficient approach to build nested Elements with efficient approach to build nested Elements with identifiers,
identifiers, lengths, and values. Similar to how an XML Schema lengths, and values. Similar to how an XML Schema defines the
defines the structure and semantics of an XML Document, this document structure and semantics of an XML Document, this document defines how
defines how EBML Schemas are created to convey the semantics of an EBML Schemas are created to convey the semantics of an EBML Document.
EBML Document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 June 2020. This Internet-Draft will expire on 24 June 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 4
3. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Variable Size Integer . . . . . . . . . . . . . . . . . . . . 7 4. Variable Size Integer . . . . . . . . . . . . . . . . . . . . 7
4.1. VINT_WIDTH . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. VINT_WIDTH . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. VINT_MARKER . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. VINT_MARKER . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. VINT_DATA . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. VINT_DATA . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. VINT Examples . . . . . . . . . . . . . . . . . . . . . . 8 4.4. VINT Examples . . . . . . . . . . . . . . . . . . . . . . 8
5. Element ID . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Element ID . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Element Data Size . . . . . . . . . . . . . . . . . . . . . . 11 6. Element Data Size . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Data Size Format . . . . . . . . . . . . . . . . . . . . 11 6.1. Data Size Format . . . . . . . . . . . . . . . . . . . . 11
6.2. Unknown Data Size . . . . . . . . . . . . . . . . . . . . 12 6.2. Unknown Data Size . . . . . . . . . . . . . . . . . . . . 12
6.3. Data Size Values . . . . . . . . . . . . . . . . . . . . 14 6.3. Data Size Values . . . . . . . . . . . . . . . . . . . . 14
7. EBML Element Types . . . . . . . . . . . . . . . . . . . . . 15 7. EBML Element Types . . . . . . . . . . . . . . . . . . . . . 15
7.1. Signed Integer Element . . . . . . . . . . . . . . . . . 15 7.1. Signed Integer Element . . . . . . . . . . . . . . . . . 15
7.2. Unsigned Integer Element . . . . . . . . . . . . . . . . 16 7.2. Unsigned Integer Element . . . . . . . . . . . . . . . . 16
7.3. Float Element . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Float Element . . . . . . . . . . . . . . . . . . . . . . 16
7.4. String Element . . . . . . . . . . . . . . . . . . . . . 16 7.4. String Element . . . . . . . . . . . . . . . . . . . . . 16
7.5. UTF-8 Element . . . . . . . . . . . . . . . . . . . . . . 16 7.5. UTF-8 Element . . . . . . . . . . . . . . . . . . . . . . 16
7.6. Date Element . . . . . . . . . . . . . . . . . . . . . . 17 7.6. Date Element . . . . . . . . . . . . . . . . . . . . . . 17
7.7. Master Element . . . . . . . . . . . . . . . . . . . . . 17 7.7. Master Element . . . . . . . . . . . . . . . . . . . . . 17
7.8. Binary Element . . . . . . . . . . . . . . . . . . . . . 17 7.8. Binary Element . . . . . . . . . . . . . . . . . . . . . 17
8. EBML Document . . . . . . . . . . . . . . . . . . . . . . . . 18 8. EBML Document . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. EBML Header . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. EBML Header . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . . . 18
9. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. EBML Versioning . . . . . . . . . . . . . . . . . . . . . . . 19 10. EBML Versioning . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. EBML Header Version . . . . . . . . . . . . . . . . . . 19 10.1. EBML Header Version . . . . . . . . . . . . . . . . . . 19
10.2. EBML Document Version . . . . . . . . . . . . . . . . . 19 10.2. EBML Document Version . . . . . . . . . . . . . . . . . 19
11. Elements semantic . . . . . . . . . . . . . . . . . . . . . . 19 11. Elements semantic . . . . . . . . . . . . . . . . . . . . . . 19
11.1. EBML Schema . . . . . . . . . . . . . . . . . . . . . . 19 11.1. EBML Schema . . . . . . . . . . . . . . . . . . . . . . 19
11.1.1. EBML Schema Example . . . . . . . . . . . . . . . . 20 11.1.1. EBML Schema Example . . . . . . . . . . . . . . . . 20
11.1.2. <EBMLSchema> Element . . . . . . . . . . . . . . . . 21 11.1.2. <EBMLSchema> Element . . . . . . . . . . . . . . . . 21
11.1.3. <EBMLSchema> Attributes . . . . . . . . . . . . . . 21 11.1.3. <EBMLSchema> Attributes . . . . . . . . . . . . . . 21
11.1.4. <element> Element . . . . . . . . . . . . . . . . . 22 11.1.4. <element> Element . . . . . . . . . . . . . . . . . 22
11.1.5. <element> Attributes . . . . . . . . . . . . . . . . 22 11.1.5. <element> Attributes . . . . . . . . . . . . . . . . 22
11.1.6. <documentation> Element . . . . . . . . . . . . . . 29 11.1.6. <documentation> Element . . . . . . . . . . . . . . 30
11.1.7. <documentation> Attributes . . . . . . . . . . . . . 29 11.1.7. <documentation> Attributes . . . . . . . . . . . . . 30
11.1.8. <implementation_note> Element . . . . . . . . . . . 30 11.1.8. <implementation_note> Element . . . . . . . . . . . 31
11.1.9. <implementation_note> Attributes . . . . . . . . . . 31 11.1.9. <implementation_note> Attributes . . . . . . . . . . 31
11.1.10. <restriction> Element . . . . . . . . . . . . . . . 32 11.1.10. <restriction> Element . . . . . . . . . . . . . . . 33
11.1.11. <enum> Element . . . . . . . . . . . . . . . . . . . 32 11.1.11. <enum> Element . . . . . . . . . . . . . . . . . . . 33
11.1.12. <enum> Attributes . . . . . . . . . . . . . . . . . 33 11.1.12. <enum> Attributes . . . . . . . . . . . . . . . . . 34
11.1.13. <extension> Element . . . . . . . . . . . . . . . . 33 11.1.13. <extension> Element . . . . . . . . . . . . . . . . 34
11.1.14. <extension> Attributes . . . . . . . . . . . . . . . 33 11.1.14. <extension> Attributes . . . . . . . . . . . . . . . 34
11.1.15. XML Schema for EBML Schema . . . . . . . . . . . . . 34 11.1.15. XML Schema for EBML Schema . . . . . . . . . . . . . 35
11.1.16. Identically Recurring Elements . . . . . . . . . . . 37 11.1.16. Identically Recurring Elements . . . . . . . . . . . 38
11.1.17. Textual expression of floats . . . . . . . . . . . . 38 11.1.17. Textual expression of floats . . . . . . . . . . . . 39
11.1.18. Note on the use of default attributes to define 11.1.18. Note on the use of default attributes to define
Mandatory EBML Elements . . . . . . . . . . . . . . . 39 Mandatory EBML Elements . . . . . . . . . . . . . . . 40
11.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 39 11.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 40
11.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 40 11.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 41
11.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 40 11.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 41
11.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 40 11.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 41
11.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 41 11.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 42
11.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 41 11.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 42
11.2.6. DocType Element . . . . . . . . . . . . . . . . . . 42 11.2.6. DocType Element . . . . . . . . . . . . . . . . . . 43
11.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 42 11.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 43
11.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 43 11.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 44
11.2.9. DocTypeExtension Element . . . . . . . . . . . . . . 43 11.2.9. DocTypeExtension Element . . . . . . . . . . . . . . 44
11.2.10. DocTypeExtensionName Element . . . . . . . . . . . . 44 11.2.10. DocTypeExtensionName Element . . . . . . . . . . . . 45
11.2.11. DocTypeExtensionVersion Element . . . . . . . . . . 44 11.2.11. DocTypeExtensionVersion Element . . . . . . . . . . 45
11.3. Global Elements . . . . . . . . . . . . . . . . . . . . 45 11.3. Global Elements . . . . . . . . . . . . . . . . . . . . 46
11.3.1. CRC-32 Element . . . . . . . . . . . . . . . . . . . 45 11.3.1. CRC-32 Element . . . . . . . . . . . . . . . . . . . 46
11.3.2. Void Element . . . . . . . . . . . . . . . . . . . . 46 11.3.2. Void Element . . . . . . . . . . . . . . . . . . . . 47
12. Considerations for Reading EBML Data . . . . . . . . . . . . 46 12. Considerations for Reading EBML Data . . . . . . . . . . . . 47
13. Terminating Elements . . . . . . . . . . . . . . . . . . . . 47 13. Terminating Elements . . . . . . . . . . . . . . . . . . . . 48
14. Guidelines for Updating Elements . . . . . . . . . . . . . . 48 14. Guidelines for Updating Elements . . . . . . . . . . . . . . 49
14.1. Reducing a Element Data in Size . . . . . . . . . . . . 48 14.1. Reducing a Element Data in Size . . . . . . . . . . . . 49
14.1.1. Adding a Void Element . . . . . . . . . . . . . . . 48 14.1.1. Adding a Void Element . . . . . . . . . . . . . . . 49
14.1.2. Extending the Element Data Size . . . . . . . . . . 48 14.1.2. Extending the Element Data Size . . . . . . . . . . 49
14.1.3. Terminating Element Data . . . . . . . . . . . . . . 49 14.1.3. Terminating Element Data . . . . . . . . . . . . . . 50
14.2. Considerations when Updating Elements with Cyclic 14.2. Considerations when Updating Elements with Cyclic
Redundancy Check (CRC) . . . . . . . . . . . . . . . . . 50 Redundancy Check (CRC) . . . . . . . . . . . . . . . . . 51
15. Backward and Forward Compatibility . . . . . . . . . . . . . 50 15. Backward and Forward Compatibility . . . . . . . . . . . . . 51
15.1. Backward Compatibility . . . . . . . . . . . . . . . . . 50 15.1. Backward Compatibility . . . . . . . . . . . . . . . . . 51
15.2. Forward Compatibility . . . . . . . . . . . . . . . . . 51 15.2. Forward Compatibility . . . . . . . . . . . . . . . . . 52
16. Security Considerations . . . . . . . . . . . . . . . . . . . 51 16. Security Considerations . . . . . . . . . . . . . . . . . . . 52
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
17.1. CELLAR EBML Element ID Registry . . . . . . . . . . . . 52 17.1. EBML Element ID Registry . . . . . . . . . . . . . . . . 53
17.2. CELLAR EBML DocType Registry . . . . . . . . . . . . . . 56 17.2. EBML DocType Registry . . . . . . . . . . . . . . . . . 57
18. Normative References . . . . . . . . . . . . . . . . . . . . 56 18. Normative References . . . . . . . . . . . . . . . . . . . . 57
19. Informative References . . . . . . . . . . . . . . . . . . . 58 19. Informative References . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
EBML, short for Extensible Binary Meta Language, specifies a binary EBML, short for Extensible Binary Meta Language, specifies a binary
and octet (byte) aligned format inspired by the principle of XML (a and octet (byte) aligned format inspired by the principle of XML (a
framework for structuring data). framework for structuring data).
The goal of this document is to define a generic, binary, space- The goal of this document is to define a generic, binary, space-
efficient format that can be used to define more complex formats efficient format that can be used to define more complex formats
using an EBML Schema. EBML is used by the multimedia container, using an EBML Schema. EBML is used by the multimedia container,
skipping to change at page 7, line 24 skipping to change at page 7, line 16
The Element ID and Element Data Size are both encoded as a Variable The Element ID and Element Data Size are both encoded as a Variable
Size Integer. The Variable Size Integer is composed of a VINT_WIDTH, Size Integer. The Variable Size Integer is composed of a VINT_WIDTH,
VINT_MARKER, and VINT_DATA, in that order. Variable Size Integers VINT_MARKER, and VINT_DATA, in that order. Variable Size Integers
MUST left-pad the VINT_DATA value with zero bits so that the whole MUST left-pad the VINT_DATA value with zero bits so that the whole
Variable Size Integer is octet-aligned. Variable Size Integer will Variable Size Integer is octet-aligned. Variable Size Integer will
be referred to as VINT for shorthand. be referred to as VINT for shorthand.
4.1. VINT_WIDTH 4.1. VINT_WIDTH
Each Variable Size Integer begins with a VINT_WIDTH which consists of Each Variable Size Integer starts with a VINT_WIDTH followed by a
zero or many zero-value bits. The count of consecutive zero-values VINT_MARKER. VINT_WIDTH is a sequence of zero or more bits of value
of the VINT_WIDTH plus one equals the length in octets of the "0", and is terminated by the VINT_MARKER, which is a single bit of
Variable Size Integer. For example, a Variable Size Integer that value "1". The total length in bits of both VINT_WIDTH and
starts with a VINT_WIDTH which contains zero consecutive zero-value VINT_MARKER is the total length in octets in of the Variable Size
bits is one octet in length and a Variable Size Integer that starts Integer.
with one consecutive zero-value bit is two octets in length. The
VINT_WIDTH MUST only contain zero-value bits or be empty.
Within the EBML Header the VINT_WIDTH of a VINT MUST NOT exceed three The single bit "1" starts a Variable Size Integer with a length of
bits in length (meaning that the Variable Size Integer MUST NOT one octet. The sequence of bits "01" starts a Variable Size Integer
exceed four octets in length) except if said VINT is used to express with a length of two octets. "001" starts a Variable Size Integer
the Element Data Size of an EBML Element with Element Name EBML and with a length of three octets, and so on, with each additional 0-bit
Element ID "0x1A45DFA3" (see Section 11.2.1) in which case the adding one octet to the length of the Variable Size Integer.
VINT_WIDTH MUST NOT exceed seven bits in length. Within the EBML
Body, when a VINT is used to express an Element ID, the maximum
length allowed for the VINT_WIDTH is one less than the value set in
the EBMLMaxIDLength Element. Within the EBML Body, when a VINT is
used to express an Element Data Size, the maximum length allowed for
the VINT_WIDTH is one less than the value set in the
EBMLMaxSizeLength Element.
4.2. VINT_MARKER 4.2. VINT_MARKER
The VINT_MARKER serves as a separator between the VINT_WIDTH and The VINT_MARKER serves as a separator between the VINT_WIDTH and
VINT_DATA. Each Variable Size Integer MUST contain exactly one VINT_DATA. Each Variable Size Integer MUST contain exactly one
VINT_MARKER. The VINT_MARKER is one bit in length and contain a bit VINT_MARKER. The VINT_MARKER is one bit in length and contain a bit
with a value of one. The first bit with a value of one within the with a value of one. The first bit with a value of one within the
Variable Size Integer is the VINT_MARKER. Variable Size Integer is the VINT_MARKER.
4.3. VINT_DATA 4.3. VINT_DATA
skipping to change at page 8, line 45 skipping to change at page 8, line 31
+--------------+-------------+-------------------------------+ +--------------+-------------+-------------------------------+
| 4 | 28 | 0001 xxxx xxxx xxxx xxxx xxxx | | 4 | 28 | 0001 xxxx xxxx xxxx xxxx xxxx |
| | | xxxx xxxx | | | | xxxx xxxx |
+--------------+-------------+-------------------------------+ +--------------+-------------+-------------------------------+
| 5 | 35 | 0000 1xxx xxxx xxxx xxxx xxxx | | 5 | 35 | 0000 1xxx xxxx xxxx xxxx xxxx |
| | | xxxx xxxx xxxx xxxx | | | | xxxx xxxx xxxx xxxx |
+--------------+-------------+-------------------------------+ +--------------+-------------+-------------------------------+
Table 1: VINT examples depicting usable bits Table 1: VINT examples depicting usable bits
Data encoded as a Variable Size Integer may be rendered at octet A Variable Size Integer may be rendered at octet lengths larger than
lengths larger than needed to store the data in order to facilitate needed to store the data in order to facilitate overwriting it at a
overwriting it at a later date, e.g. when its final size isn't known later date, e.g. when its final size isn't known in advance. In
in advance. In Table 2 a binary value of 0b10 is shown encoded as Table 2 an integer "2" (with a corresponding binary value of 0b10) is
different Variable Size Integers with lengths from one octet to four shown encoded as different Variable Size Integers with lengths from
octets. All four encoded examples have identical semantic meaning one octet to four octets. All four encoded examples have identical
though the VINT_WIDTH and the padding of the VINT_DATA vary. semantic meaning though the VINT_WIDTH and the padding of the
VINT_DATA vary.
+--------------+--------------+-----------------------+ +---------+--------------+---------------------+--------------------+
| Binary Value | Octet Length | As Represented in | | Integer | Octet | As Represented in | As Represented in |
| | | Variable Size Integer | | | Length | VINT (binary) | VINT (hexadecimal) |
+==============+==============+=======================+ +=========+==============+=====================+====================+
| 10 | 1 | 1000 0010 | | 2 | 1 | 1000 0010 | 0x82 |
+--------------+--------------+-----------------------+ +---------+--------------+---------------------+--------------------+
| 10 | 2 | 0100 0000 0000 0010 | | 2 | 2 | 0100 0000 0000 0010 | 0x4002 |
+--------------+--------------+-----------------------+ +---------+--------------+---------------------+--------------------+
| 10 | 3 | 0010 0000 0000 0000 | | 2 | 3 | 0010 0000 0000 0000 | 0x200002 |
| | | 0000 0010 | | | | 0000 0010 | |
+--------------+--------------+-----------------------+ +---------+--------------+---------------------+--------------------+
| 10 | 4 | 0001 0000 0000 0000 | | 2 | 4 | 0001 0000 0000 0000 | 0x10000002 |
| | | 0000 0000 0000 0010 | | | | 0000 0000 0000 0010 | |
+--------------+--------------+-----------------------+ +---------+--------------+---------------------+--------------------+
Table 2: VINT examples depicting the same integer Table 2: VINT examples depicting the same integer value rendered
value rendered at different VINT sizes at different VINT lengths
5. Element ID 5. Element ID
The Element ID is encoded as a Variable Size Integer. By default, An Element ID is a Variable Size Integer. By default, Element IDs
Element IDs are encoded in lengths from one octet to four octets, are from one octet to four octets in length, although Element IDs of
although Element IDs of greater lengths MAY be used if the greater lengths MAY be used if the EBMLMaxIDLength Element of the
EBMLMaxIDLength Element of the EBML Header is set to a value greater EBML Header is set to a value greater than four (see Section 11.2.4).
than four (see Section 11.2.4). The VINT_DATA component of the The bits of the VINT_DATA component of the Element ID MUST NOT be all
Element ID MUST NOT be either defined or written as either all zero "0" values or all "1" values. The VINT_DATA component of the Element
values or all one values. Any Element ID with the VINT_DATA ID MUST be encoded at the shortest valid length. For example, an
component set as all zero values or all one values MUST be ignored. Element ID with binary encoding of "1011 1111" is valid, whereas an
The VINT_DATA component of the Element ID MUST be encoded at the Element ID with binary encoding of "0100 0000 0011 1111" stores a
shortest valid length. For example, an Element ID with binary semantically equal VINT_DATA but is invalid because a shorter VINT
encoding of "1011 1111" is valid, whereas an Element ID with binary encoding is possible. Additionally, an Element ID with binary
encoding of "0100 0000 0011 1111" stores a semantically equal encoding of "1111 1111" is invalid since the VINT_DATA section is set
VINT_DATA but is invalid because a shorter VINT encoding is possible. to all one values, whereas an Element ID with binary encoding of
Additionally, an Element ID with binary encoding of "1111 1111" is "0100 0000 0111 1111" stores a semantically equal VINT_DATA and is
invalid since the VINT_DATA section is set to all one values, whereas the shortest possible VINT encoding.
an Element ID with binary encoding of "0100 0000 0111 1111" stores a
semantically equal VINT_DATA and is the shortest possible VINT
encoding.
Table 3 details these specific examples further: Table 3 details these specific examples further:
+------------+-------------+----------------+--------------------+ +------------+-------------+----------------+--------------------+
| VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status | | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status |
+============+=============+================+====================+ +============+=============+================+====================+
| | 1 | 0000000 | Invalid: VINT_DATA | | | 1 | 0000000 | Invalid: VINT_DATA |
| | | | MUST NOT be set to | | | | | MUST NOT be set to |
| | | | all 0 | | | | | all 0 |
+------------+-------------+----------------+--------------------+ +------------+-------------+----------------+--------------------+
skipping to change at page 10, line 35 skipping to change at page 10, line 35
| | | | VINT_DATA encoding | | | | | VINT_DATA encoding |
| | | | is available. | | | | | is available. |
+------------+-------------+----------------+--------------------+ +------------+-------------+----------------+--------------------+
| | 1 | 1111111 | Invalid: VINT_DATA | | | 1 | 1111111 | Invalid: VINT_DATA |
| | | | MUST NOT be set to | | | | | MUST NOT be set to |
| | | | all 1 | | | | | all 1 |
+------------+-------------+----------------+--------------------+ +------------+-------------+----------------+--------------------+
| 0 | 1 | 00000001111111 | Valid | | 0 | 1 | 00000001111111 | Valid |
+------------+-------------+----------------+--------------------+ +------------+-------------+----------------+--------------------+
Table 3: Examples of valid and invalid VINTs Table 3: Examples of valid and invalid Element IDs
The range and count of VINT_DATA values is determined by the octet The range and count of possible Element IDs are determined by their
length of the VINT. Examples of this are provided in Table 4. octet length. Examples of this are provided in Table 4.
+-----------------------+-------------------------+---------------+ +-------------------------+----------------+-----------------+
| VINT Length in octets | Range of Possible IDs | Number of IDs | | Element ID Octet Length | Range of Valid | Number of Valid |
+=======================+=========================+===============+ | | Element IDs | Element IDs |
| 1 | 0x81 - 0xFE | 126 | +=========================+================+=================+
+-----------------------+-------------------------+---------------+ | 1 | 0x81 - 0xFE | 126 |
| 2 | 0x407F - 0x7FFE | 16,256 | +-------------------------+----------------+-----------------+
+-----------------------+-------------------------+---------------+ | 2 | 0x407F - | 16,256 |
| 3 | 0x203FFF - 0x3FFFFE | 2,080,768 | | | 0x7FFE | |
+-----------------------+-------------------------+---------------+ +-------------------------+----------------+-----------------+
| 4 | 0x101FFFFF - 0x1FFFFFFE | 268,338,304 | | 3 | 0x203FFF - | 2,080,768 |
+-----------------------+-------------------------+---------------+ | | 0x3FFFFE | |
+-------------------------+----------------+-----------------+
| 4 | 0x101FFFFF - | 268,338,304 |
| | 0x1FFFFFFE | |
+-------------------------+----------------+-----------------+
Table 4: Examples of count and range for VINT_DATA per VINT Table 4: Examples of count and range for Element IDs at
length in octets various octet lengths
6. Element Data Size 6. Element Data Size
6.1. Data Size Format 6.1. Data Size Format
The Element Data Size expresses the length in octets of Element Data. The Element Data Size expresses the length in octets of Element Data.
The Element Data Size itself is encoded as a Variable Size Integer. The Element Data Size itself is encoded as a Variable Size Integer.
By default, Element Data Sizes can be encoded in lengths from one By default, Element Data Sizes can be encoded in lengths from one
octet to eight octets, although Element Data Sizes of greater lengths octet to eight octets, although Element Data Sizes of greater lengths
MAY be used if the octet length of the longest Element Data Size of MAY be used if the octet length of the longest Element Data Size of
skipping to change at page 12, line 11 skipping to change at page 12, line 13
use the value of the Empty Element for the corresponding EBML Element use the value of the Empty Element for the corresponding EBML Element
Type of the Element ID, 0 for numbers and an empty string for Type of the Element ID, 0 for numbers and an empty string for
strings. strings.
6.2. Unknown Data Size 6.2. Unknown Data Size
An Element Data Size with all VINT_DATA bits set to one is reserved An Element Data Size with all VINT_DATA bits set to one is reserved
as an indicator that the size of the EBML Element is unknown. The as an indicator that the size of the EBML Element is unknown. The
only reserved value for the VINT_DATA of Element Data Size is all only reserved value for the VINT_DATA of Element Data Size is all
bits set to one. An EBML Element with an unknown Element Data Size bits set to one. An EBML Element with an unknown Element Data Size
is referred to as an Unknown-Sized Element. A Master Element MAY be is referred to as an Unknown-Sized Element. Only a Master Element is
an Unknown-Sized Element; however an EBML Element that is not a allowed to be of unknown size, and it can only be so if the
Master Element MUST NOT be an Unknown-Sized Element. Master Elements unknownsizeallowed attribute of its EBML Schema is set to true (see
MUST NOT use an unknown size unless the unknownsizeallowed attribute Section 11.1.5.10).
of their EBML Schema is set to true (see Section 11.1.5.10).
The use of Unknown-Sized Elements allows for an EBML Element to be The use of Unknown-Sized Elements allows for an EBML Element to be
written and read before the size of the EBML Element is known. written and read before the size of the EBML Element is known.
Unknown-Sized Elements MUST only be used if the Element Data Size is Unknown-Sized Elements MUST only be used if the Element Data Size is
not known before the Element Data is written, such as in some cases not known before the Element Data is written, such as in some cases
of data streaming. The end of an Unknown-Sized Element is determined of data streaming. The end of an Unknown-Sized Element is determined
by whichever comes first: by whichever comes first:
* Any EBML Element that is a valid Parent Element of the Unknown- * Any EBML Element that is a valid Parent Element of the Unknown-
Sized Element according to the EBML Schema, Global Elements Sized Element according to the EBML Schema, Global Elements
skipping to change at page 14, line 17 skipping to change at page 14, line 17
For Element Data Sizes encoded at octet lengths from one to eight, For Element Data Sizes encoded at octet lengths from one to eight,
Table 6 depicts the range of possible values that can be encoded as Table 6 depicts the range of possible values that can be encoded as
an Element Data Size. An Element Data Size with an octet length of 8 an Element Data Size. An Element Data Size with an octet length of 8
is able to express a size of 2^56-2 or 72,057,594,037,927,934 octets is able to express a size of 2^56-2 or 72,057,594,037,927,934 octets
(or about 72 petabytes). The maximum possible value that can be (or about 72 petabytes). The maximum possible value that can be
stored as Element Data Size is referred to as VINTMAX. stored as Element Data Size is referred to as VINTMAX.
+--------------+----------------------+ +--------------+----------------------+
| Octet Length | Possible Value Range | | Octet Length | Possible Value Range |
+==============+======================+ +==============+======================+
| 1 | 0 to 2^(7-2) | | 1 | 0 to 2^7 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 2 | 0 to 2^(14-2) | | 2 | 0 to 2^14 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 3 | 0 to 2^(21-2) | | 3 | 0 to 2^21 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 4 | 0 to 2^(28-2) | | 4 | 0 to 2^28 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 5 | 0 to 2^(35-2) | | 5 | 0 to 2^35 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 6 | 0 to 2^(42-2) | | 6 | 0 to 2^42 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 7 | 0 to 2^(49-2) | | 7 | 0 to 2^49 - 2 |
+--------------+----------------------+ +--------------+----------------------+
| 8 | 0 to 2^(56-2) | | 8 | 0 to 2^56 - 2 |
+--------------+----------------------+ +--------------+----------------------+
Table 6: Possible range of values Table 6: Possible range of values
that can be stored in VINTs by that can be stored in VINTs by
octet length. octet length.
If the length of Element Data equals 2^(n*7)-1 then the octet length If the length of Element Data equals 2^(n*7)-1 then the octet length
of the Element Data Size MUST be at least n+1. This rule prevents an of the Element Data Size MUST be at least n+1. This rule prevents an
Element Data Size from being expressed as the unknown size value. Element Data Size from being expressed as the unknown size value.
Table 7 clarifies this rule by showing a valid and invalid expression Table 7 clarifies this rule by showing a valid and invalid expression
skipping to change at page 16, line 33 skipping to change at page 16, line 33
Unsigned Integer Element stores a number from 0 to Unsigned Integer Element stores a number from 0 to
18,446,744,073,709,551,615. 18,446,744,073,709,551,615.
7.3. Float Element 7.3. Float Element
A Float Element MUST declare a length of either zero octet (0 bit), A Float Element MUST declare a length of either zero octet (0 bit),
four octets (32 bit) or eight octets (64 bit). If the EBML Element four octets (32 bit) or eight octets (64 bit). If the EBML Element
is not defined to have a default value, then a Float Element with a is not defined to have a default value, then a Float Element with a
zero-octet length represents a numerical value of zero. zero-octet length represents a numerical value of zero.
A Float Element stores a floating-point number as defined in A Float Element stores a floating-point number in the 32-bit and
[IEEE.754.1985]. 64-bit binary interchange format as defined in [IEEE.754.1985].
7.4. String Element 7.4. String Element
A String Element MUST declare a length in octets from zero to A String Element MUST declare a length in octets from zero to
VINTMAX. If the EBML Element is not defined to have a default value, VINTMAX. If the EBML Element is not defined to have a default value,
then a String Element with a zero-octet length represents an empty then a String Element with a zero-octet length represents an empty
string. string.
A String Element MUST either be empty (zero-length) or contain A String Element MUST either be empty (zero-length) or contain
printable ASCII characters [RFC0020] in the range of 0x20 to 0x7E, printable ASCII characters [RFC0020] in the range of 0x20 to 0x7E,
skipping to change at page 17, line 25 skipping to change at page 17, line 25
The Date Element stores an integer in the same format as the Signed The Date Element stores an integer in the same format as the Signed
Integer Element that expresses a point in time referenced in Integer Element that expresses a point in time referenced in
nanoseconds from the precise beginning of the third millennium of the nanoseconds from the precise beginning of the third millennium of the
Gregorian Calendar in Coordinated Universal Time (also known as Gregorian Calendar in Coordinated Universal Time (also known as
2001-01-01T00:00:00.000000000 UTC). This provides a possible 2001-01-01T00:00:00.000000000 UTC). This provides a possible
expression of time from 1708-09-11T00:12:44.854775808 UTC to expression of time from 1708-09-11T00:12:44.854775808 UTC to
2293-04-11T11:47:16.854775807 UTC. 2293-04-11T11:47:16.854775807 UTC.
7.7. Master Element 7.7. Master Element
A Master Element MUST declare a length in octets from zero to A Master Element MUST declare a length in octets from zero to VINTMAX
VINTMAX. The Master Element MAY also use an unknown length. See or be of unknown length. See Section 6 for rules that apply to
Section 6 for rules that apply to elements of unknown length. elements of unknown length.
The Master Element contains zero, one, or many other elements. EBML The Master Element contains zero or more other elements. EBML
Elements contained within a Master Element MUST have the Elements contained within a Master Element MUST have the
EBMLParentPath of their Element Path equal to the EBMLFullPath of the EBMLParentPath of their Element Path equal to the EBMLFullPath of the
Master Element Element Path (see Section 11.1.5.2). Element Data Master Element Element Path (see Section 11.1.5.2). Element Data
stored within Master Elements SHOULD only consist of EBML Elements stored within Master Elements SHOULD only consist of EBML Elements
and SHOULD NOT contain any data that is not part of an EBML Element. and SHOULD NOT contain any data that is not part of an EBML Element.
The EBML Schema identifies what Element IDs are valid within the The EBML Schema identifies what Element IDs are valid within the
Master Elements for that version of the EBML Document Type. Any data Master Elements for that version of the EBML Document Type. Any data
contained within a Master Element that is not part of a Child Element contained within a Master Element that is not part of a Child Element
MUST be ignored. MUST be ignored.
7.8. Binary Element 7.8. Binary Element
A Binary Element MUST declare a length in octets from zero to A Binary Element MUST declare a length in octets from zero to
VINTMAX. VINTMAX.
The contents of a Binary Element should not be interpreted by the The contents of a Binary Element should not be interpreted by the
EBML Reader. EBML Reader.
8. EBML Document 8. EBML Document
An EBML Document is comprised of only two components, an EBML Header An EBML Document is composed of only two components, an EBML Header
and an EBML Body. An EBML Document MUST start with an EBML Header and an EBML Body. An EBML Document MUST start with an EBML Header
that declares significant characteristics of the entire EBML Body. that declares significant characteristics of the entire EBML Body.
An EBML Document consists of EBML Elements and MUST NOT contain any An EBML Document consists of EBML Elements and MUST NOT contain any
data that is not part of an EBML Element. data that is not part of an EBML Element.
8.1. EBML Header 8.1. EBML Header
The EBML Header is a declaration that provides processing The EBML Header is a declaration that provides processing
instructions and identification of the EBML Body. The EBML Header of instructions and identification of the EBML Body. The EBML Header of
an EBML Document is analogous to the XML Declaration of an XML an EBML Document is analogous to the XML Declaration of an XML
skipping to change at page 18, line 33 skipping to change at page 18, line 33
the versions of both EBML and the EBML Schema that were used to write the versions of both EBML and the EBML Schema that were used to write
the EBML Document and the versions required to read the EBML the EBML Document and the versions required to read the EBML
Document. Document.
The EBML Header MUST contain a single Master Element with an Element The EBML Header MUST contain a single Master Element with an Element
Name of EBML and Element ID of 0x1A45DFA3 (see Section 11.2.1) and Name of EBML and Element ID of 0x1A45DFA3 (see Section 11.2.1) and
any number of additional EBML Elements within it. The EBML Header of any number of additional EBML Elements within it. The EBML Header of
an EBML Document that uses an EBMLVersion of 1 MUST only contain EBML an EBML Document that uses an EBMLVersion of 1 MUST only contain EBML
Elements that are defined as part of this document. Elements that are defined as part of this document.
Elements within an EBML Header can be at most 4 octets long, except
for the EBML Element with Element Name EBML and Element ID
"0x1A45DFA3" (see Section 11.2.1), which can be up to 8 octets long.
8.2. EBML Body 8.2. EBML Body
All data of an EBML Document following the EBML Header is the EBML All data of an EBML Document following the EBML Header is the EBML
Body. The end of the EBML Body, as well as the end of the EBML Body. The end of the EBML Body, as well as the end of the EBML
Document that contains the EBML Body, is reached at whichever comes Document that contains the EBML Body, is reached at whichever comes
first: the beginning of a new EBML Header at the Root Level or the first: the beginning of a new EBML Header at the Root Level or the
end of the file. The EBML Body MUST NOT contain any data that is not end of the file. This document defines precisely which EBML Elements
part of an EBML Element. This document defines precisely which EBML are to be used within the EBML Header, but does not name or define
Elements are to be used within the EBML Header, but does not name or which EBML Elements are to be used within the EBML Body. The
define which EBML Elements are to be used within the EBML Body. The
definition of which EBML Elements are to be used within the EBML Body definition of which EBML Elements are to be used within the EBML Body
is defined by an EBML Schema. is defined by an EBML Schema.
Within the EBML Body, the maximum octet length allowed for any
Element ID is set by the EBMLMaxIDLength Element of the EBML Header
and the maximum octet length allowed for any Element Data Size is set
by the EBMLMaxSizeLength Element of the EBML Header.
9. EBML Stream 9. EBML Stream
An EBML Stream is a file that consists of one or more EBML Documents An EBML Stream is a file that consists of one or more EBML Documents
that are concatenated together. An occurrence of a EBML Header at that are concatenated together. An occurrence of a EBML Header at
the Root Level marks the beginning of an EBML Document. the Root Level marks the beginning of an EBML Document.
10. EBML Versioning 10. EBML Versioning
An EBML Document handles 2 different versions: the version of the An EBML Document handles 2 different versions: the version of the
EBML Header and the version of the EBML Body. Both versions are EBML Header and the version of the EBML Body. Both versions are
skipping to change at page 23, line 39 skipping to change at page 23, line 46
The "*", "(" and ")" symbols are interpreted as defined in [RFC5234]. The "*", "(" and ")" symbols are interpreted as defined in [RFC5234].
The EBMLPathAtom part of the EBMLElementPath MUST be equal to the The EBMLPathAtom part of the EBMLElementPath MUST be equal to the
name attribute of the EBML Schema. name attribute of the EBML Schema.
The starting PathDelimiter of the path corresponds to the root of the The starting PathDelimiter of the path corresponds to the root of the
EBML Document. EBML Document.
In some cases the EBMLLastParent part of the path is an In some cases the EBMLLastParent part of the path is an
EBMLGlobalParent. A path with a EBMLGlobalParent defines a EBMLGlobalParent. A path with a EBMLGlobalParent defines a Global
Section 11.3. Any path that starts with the EBMLFixedParent of the Element; see Section 11.3. Any path that starts with the
Global Element and matches the occurrences found in the EBMLFixedParent of the Global Element and matches the occurrences
GlobalParentOccurence is a valid path for the Global Element. found in the GlobalParentOccurence is a valid path for the Global
Element.
The GlobalParentOccurence part is interpreted as an ABNF Variable The GlobalParentOccurence part is interpreted as an ABNF Variable
Repetition. The repetition amounts correspond to the amount of Repetition. The repetition amounts correspond to the amount of
unspecified Parent Element levels there can be between the unspecified Parent Element levels there can be between the
EBMLFixedParent and the actual EBMLElementPath. EBMLFixedParent and the actual EBMLElementPath.
PathMinOccurrence represents the minimum number of element path PathMinOccurrence represents the minimum number of element path
required between the EBMLFixedParent and the Global Element required between the EBMLFixedParent and the Global Element
EBMLElementPath. For example 0 means the EBMLElementPath can be EBMLElementPath. For example 0 means the EBMLElementPath can be
right after the EBMLFixedParent, 1 means there has to be at least an right after the EBMLFixedParent, 1 means there has to be at least an
skipping to change at page 24, line 26 skipping to change at page 24, line 36
If the path contains an EBMLPathAtomRecursive part, the EBML Element If the path contains an EBMLPathAtomRecursive part, the EBML Element
can occur within itself recursively (see Section 11.1.5.11). can occur within itself recursively (see Section 11.1.5.11).
As an example, a "path" of "1*(\Segment\Info)" means the element Info As an example, a "path" of "1*(\Segment\Info)" means the element Info
is found inside the Segment elements at least once and with no is found inside the Segment elements at least once and with no
maximum iteration. An element SeekHead with path maximum iteration. An element SeekHead with path
"0*2(\Segment\SeekHead)" may not be found at all in its Segment "0*2(\Segment\SeekHead)" may not be found at all in its Segment
parent, once or twice but no more than that. parent, once or twice but no more than that.
The "@path" value MUST be unique within the EBML Schema. The "@id"
value corresponding to this "@path" MUST NOT be defined for use
within another EBML Element with the same EBMLParentPath as this
"@path".
11.1.5.3. id 11.1.5.3. id
Within an EBML Schema, the XPath of "@id" attribute is "/EBMLSchema/ Within an EBML Schema, the XPath of "@id" attribute is "/EBMLSchema/
element/@id". element/@id".
The Element ID encoded as a Variable Size Integer expressed in The Element ID encoded as a Variable Size Integer expressed in
hexadecimal notation prefixed by a 0x that is read and stored in big- hexadecimal notation prefixed by a 0x that is read and stored in big-
endian order. To reduce the risk of false positives while parsing endian order. To reduce the risk of false positives while parsing
EBML Streams, the Element IDs of the Root Element and Top-Level EBML Streams, the Element IDs of the Root Element and Top-Level
Elements SHOULD be at least 4 octets in length. Element IDs defined Elements SHOULD be at least 4 octets in length. Element IDs defined
for use at Root Level or directly under the Root Level MAY use for use at Root Level or directly under the Root Level MAY use
shorter octet lengths to facilitate padding and optimize edits to shorter octet lengths to facilitate padding and optimize edits to
EBML Documents; for instance, the Void Element uses an Element ID EBML Documents; for instance, the Void Element uses an Element ID
with a one octet length to allow its usage in more writing and with a one octet length to allow its usage in more writing and
editing scenarios. editing scenarios.
The Element ID of any Element found within an EBML Document MUST only
match a single "@path" value of its corresponding EBML Schema, but a
separate instance of that Element ID value defined by the EBML Schema
MAY occur within a different "@path". If more than one Element is
defined to use the same "@id" value, then the "@path" values of those
Elements MUST NOT share the same EBMLParentPath. Elements MUST NOT
be defined to use the same "@id" value if one of their common Parent
Elements could be an Unknown-Size Element.
The id attribute is REQUIRED. The id attribute is REQUIRED.
11.1.5.4. minOccurs 11.1.5.4. minOccurs
Within an EBML Schema, the XPath of "@minOccurs" attribute is Within an EBML Schema, the XPath of "@minOccurs" attribute is
"/EBMLSchema/element/@minOccurs". "/EBMLSchema/element/@minOccurs".
The minOccurs is a non-negative integer expressing the minimum The minOccurs is a non-negative integer expressing the minimum
permitted number of occurrences of this EBML Element within its permitted number of occurrences of this EBML Element within its
Parent Element. Parent Element.
skipping to change at page 28, line 51 skipping to change at page 29, line 27
The recursive attribute is OPTIONAL. If the recursive attribute is The recursive attribute is OPTIONAL. If the recursive attribute is
not present then the EBML Element MUST NOT be used recursively. not present then the EBML Element MUST NOT be used recursively.
11.1.5.12. recurring 11.1.5.12. recurring
Within an EBML Schema, the XPath of "@recurring" attribute is Within an EBML Schema, the XPath of "@recurring" attribute is
"/EBMLSchema/element/@recurring". "/EBMLSchema/element/@recurring".
A boolean to express if an EBML Element is defined as an Identically A boolean to express if an EBML Element is defined as an Identically
Recurring Element or not. Recurring Element or not; see Section 11.1.16.
The recurring attribute is OPTIONAL. If the recurring attribute is The recurring attribute is OPTIONAL. If the recurring attribute is
not present then the EBML Element is not an Identically Recurring not present then the EBML Element is not an Identically Recurring
Element. Element.
11.1.5.13. minver 11.1.5.13. minver
Within an EBML Schema, the XPath of "@minver" attribute is Within an EBML Schema, the XPath of "@minver" attribute is
"/EBMLSchema/element/@minver". "/EBMLSchema/element/@minver".
skipping to change at page 49, line 46 skipping to change at page 50, line 46
| Before | 0x3B4040 | 0x4003 | 0x6D6B76 | | | Before | 0x3B4040 | 0x4003 | 0x6D6B76 | |
+--------+------------+-------------------+--------------+---------+ +--------+------------+-------------------+--------------+---------+
| After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 | | After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 |
+--------+------------+-------------------+--------------+---------+ +--------+------------+-------------------+--------------+---------+
Table 13: Example of editing a VINT to reduce VINT_DATA length Table 13: Example of editing a VINT to reduce VINT_DATA length
by more than one octet. by more than one octet.
14.1.3. Terminating Element Data 14.1.3. Terminating Element Data
For String Elements and UTF-8 Elements the length of Element Data MAY For String Elements and UTF-8 Elements the length of Element Data
be reduced by adding Null Octets to terminate the Element Data (see could be reduced by adding Null Octets to terminate the Element Data
Section 13). (see Section 13).
In Table 14, a four octets long Element Data is changed to a three In Table 14, a four octets long Element Data is changed to a three
octet long value followed by a Null Octet; the Element Data Size octet long value followed by a Null Octet; the Element Data Size
includes any Null Octets used to terminate Element Data so remains includes any Null Octets used to terminate Element Data so remains
unchanged. unchanged.
+-------------+------------+-------------------+--------------+ +-------------+------------+-------------------+--------------+
| Status | Element ID | Element Data Size | Element Data | | Status | Element ID | Element Data Size | Element Data |
+=============+============+===================+==============+ +=============+============+===================+==============+
| Before edit | 0x3B4040 | 0x84 | 0x65626D6C | | Before edit | 0x3B4040 | 0x84 | 0x65626D6C |
skipping to change at page 52, line 47 skipping to change at page 53, line 47
that contain invalid CRC-32 Elements. EBML Readers not checking that contain invalid CRC-32 Elements. EBML Readers not checking
the CRC-32 might use the version of the element with mismatching the CRC-32 might use the version of the element with mismatching
CRC-32. CRC-32.
* Use of Void Elements which could be used to hide content or create * Use of Void Elements which could be used to hide content or create
bogus resynchronization points seen by some EBML Reader and not bogus resynchronization points seen by some EBML Reader and not
others. others.
17. IANA Considerations 17. IANA Considerations
17.1. CELLAR EBML Element ID Registry 17.1. EBML Element ID Registry
This document creates a new IANA Registry called "CELLAR EBML Element This document creates a new IANA Registry called "EBML Element ID
ID Registry". Registry".
Element IDs are described in section Element ID. Element IDs are Element IDs are described in section Element ID. Element IDs are
encoded using the VINT mechanism described in section Section 4 can encoded using the VINT mechanism described in section Section 4 can
be between one and five octets long. Five octet long Element IDs are be between one and five octets long. Five octet long Element IDs are
possible only if declared in the header. possible only if declared in the header.
This IANA Registry only applies to Elements that can be contained in This IANA Registry only applies to Elements that can be contained in
the EBML Header, thus including Global Elements. Elements only found the EBML Header, thus including Global Elements. Elements only found
in the EBML Body have their own set of independent Element IDs and in the EBML Body have their own set of independent Element IDs and
are not part of this IANA Registry. are not part of this IANA Registry.
The VINT Data value of one-octet Element IDs MUST be between 0x01 and One-octet Element IDs MUST be between 0x81 and 0xFE. These items are
0x7E. These items are valuable because they are short, and need to valuable because they are short, and need to be used for commonly
be used for commonly repeated elements. Values from 1 to 126 are to repeated elements. Element IDs are to be allocated within this range
be allocated according to the "RFC Required" policy [RFC8126]. according to the "RFC Required" policy [RFC8126].
The VINT Data value of two-octet Element IDs MUST be between 0x007F The following one-octet Element IDs are RESERVED: 0xFF and 0x80.
and 0x3FFE. Numbers are to be allocated within this range according
to the "Specification Required" policy [RFC8126].
The numbers 0x3FFF and 0x4000 are RESERVED. The one-octet range of 0x00 to 0x7F are not valid for use as an
Element ID.
The VINT Data value of three-octet Element IDs MUST be between 0x4001 Two-octet Element IDs MUST be between 0x407F and 0x7FFE. Element IDs
and 0x1FFFFE. Numbers may be allocated within this range according are to be allocated within this range according to the "Specification
to the "First Come First Served" policy [RFC8126]. Required" policy [RFC8126].
The numbers 0x1FFFFF and 0x200000 are RESERVED. The following two-octet Element IDs are RESERVED: 0x7FFF and 0x4000.
Four-octet Element IDs are numbers between 0x101FFFFF and 0x1FFFFFFE. The two-octet ranges of 0x0000 to 0x3FFF and 0x8000 to 0xFFFF are not
valid for use as an Element ID.
Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE.
Element IDs are to be allocated within this range according to the
"First Come First Served" policy [RFC8126].
The following three-octet Element IDs are RESERVED: 0x3FFFFF and
0x200000.
The three-octet ranges of 0x000000 to 0x1FFFFF and 0x400000 to
0xFFFFFF are not valid for use as an Element ID.
Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE.
Four-octet Element IDs are somewhat special in that they are useful Four-octet Element IDs are somewhat special in that they are useful
for resynchronizing to major structures in the event of data for resynchronizing to major structures in the event of data
corruption or loss. As such four-octet Element IDs are split into corruption or loss. As such four-octet Element IDs are split into
two categories. Four-octet Element IDs whose lower three octets (as two categories. Four-octet Element IDs whose lower three octets (as
encoded) would make printable 7-bit ASCII values (0x20 to 0x7E, encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
inclusive) MUST be allocated by the "Specification Required" policy. inclusive) MUST be allocated by the "Specification Required" policy.
Sequential allocation of values is not required: specifications Sequential allocation of values is not required: specifications
SHOULD include a specific request, and are encouraged to do early SHOULD include a specific request, and are encouraged to do early
allocations. allocations.
To be clear about the above category: four-octet Element IDs always To be clear about the above category: four-octet Element IDs always
start with hex 0x10 to 0x1F, and that octet may be chosen so that the start with hex 0x10 to 0x1F, and that octet may be chosen so that the
entire number has some desirable property, such as a specific CRC. entire VINT has some desirable property, such as a specific CRC. The
The other three octets, when ALL having values between 0x21 (33, other three octets, when ALL having values between 0x20 (32, ASCII
ASCII !) and 0x7E (126, ASCII ~), fall into this category. Space) and 0x7E (126, ASCII "~"), fall into this category.
Other four-octet Element IDs may be allocated by the "First Come Other four-octet Element IDs may be allocated by the "First Come
First Served" policy. First Served" policy.
The numbers 0xFFFFFFF and 0x1000000 are RESERVED. The following four-octet Element IDs are RESERVED: 0x1FFFFFFF and
0x10000000.
Five octet Element IDs (values from 0x10000001 upwards) are RESERVED The four-octet ranges of 0x00000000 to 0x0FFFFFFF and 0x20000000 to
according to the "Experimental Use" policy [RFC8126]: they may be 0xFFFFFFFF are not valid for use as an Element ID.
used by anyone at any time, but there is no coordination.
Five-octet Element IDs (values from 0x080FFFFFFF to 0x0FFFFFFFFE) are
RESERVED according to the "Experimental Use" policy [RFC8126]: they
may be used by anyone at any time, but there is no coordination.
ID Values found in this document are assigned as initial values as ID Values found in this document are assigned as initial values as
follows: follows:
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
| ID | Element Name | Reference | | Element ID | Element Name | Reference |
+============+=========================+=================+ +============+=========================+=================+
| 0x1A45DFA3 | EBML | Described in | | 0x1A45DFA3 | EBML | Described in |
| | | Section 11.2.1 | | | | Section 11.2.1 |
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
| 0x4286 | EBMLVersion | Described in | | 0x4286 | EBMLVersion | Described in |
| | | Section 11.2.2 | | | | Section 11.2.2 |
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
| 0x42F7 | EBMLReadVersion | Described in | | 0x42F7 | EBMLReadVersion | Described in |
| | | Section 11.2.3 | | | | Section 11.2.3 |
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
skipping to change at page 56, line 5 skipping to change at page 57, line 5
| 0xBF | CRC-32 | Described in | | 0xBF | CRC-32 | Described in |
| | | Section 11.3.1 | | | | Section 11.3.1 |
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
| 0xEC | Void | Described in | | 0xEC | Void | Described in |
| | | Section 11.3.2 | | | | Section 11.3.2 |
+------------+-------------------------+-----------------+ +------------+-------------------------+-----------------+
Table 15: IDs and Names for EBML Elements assigned by Table 15: IDs and Names for EBML Elements assigned by
this document. this document.
17.2. CELLAR EBML DocType Registry 17.2. EBML DocType Registry
This document creates a new IANA Registry called "CELLAR EBML DocType This document creates a new IANA Registry called "EBML DocType
Registry". Registry".
To register a new DocType in this registry one needs a DocType name, To register a new DocType in this registry one needs a DocType name,
a Description of the DocType, a Change Controller (IESG or email of a Description of the DocType, a Change Controller (IESG or email of
registrant) and an optional Reference to a document describing the registrant) and an optional Reference to a document describing the
DocType. DocType.
DocType values are described in Section 11.1.3.1. DocTypes are ASCII DocType values are described in Section 11.1.3.1. DocTypes are ASCII
strings, defined in Section 7.4, which label the official name of the strings, defined in Section 7.4, which label the official name of the
EBML Document Type. The strings may be allocated according to the EBML Document Type. The strings may be allocated according to the
skipping to change at page 56, line 29 skipping to change at page 57, line 29
The use of ASCII corresponds to the types and code already in use, The use of ASCII corresponds to the types and code already in use,
the value is not meant to be visible to the user. the value is not meant to be visible to the user.
DocType string values of "matroska" and "webm" are RESERVED to the DocType string values of "matroska" and "webm" are RESERVED to the
IETF for future use. These can be assigned via the "IESG Approval" IETF for future use. These can be assigned via the "IESG Approval"
or "RFC Required" policies [RFC8126]. or "RFC Required" policies [RFC8126].
18. Normative References 18. Normative References
[ITU.V42.1994]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", 1994.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[W3C.REC-xmlschema-0-20041028] [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Writing an IANA Considerations Section in RFCs", BCP 26,
Second Edition", World Wide Web Consortium Recommendation RFC 8126, DOI 10.17487/RFC8126, June 2017,
REC-xmlschema-0-20041028, 28 October 2004, <https://www.rfc-editor.org/info/rfc8126>.
<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, 26 November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[IEEE.754.1985] [IEEE.754.1985]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic", August "Standard for Binary Floating-Point Arithmetic", August
1985. 1985.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[ITU.V42.1994] [W3C.SPSD-xhtml-basic-20180327]
International Telecommunications Union, "Error-correcting McCarron, S., "XHTML(tm) Basic 1.1 - Second Edition", 27
Procedures for DCEs Using Asynchronous-to-Synchronous March 2018.
Conversion", 1994.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[ISO.3309.1979] [ISO.3309.1979]
International Organization for Standardization, "Data International Organization for Standardization, "Data
communication - High-level data link control procedures - communication - High-level data link control procedures -
Frame structure", 1979. Frame structure", 1979.
[W3C.SPSD-xhtml-basic-20180327] [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
McCarron, S., "XHTML(tm) Basic 1.1 - Second Edition", 27 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
March 2018. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[W3C.REC-xmlschema-0-20041028]
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-0-20041028, 28 October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[ISO.9899.2011] [ISO.9899.2011]
International Organization for Standardization, International Organization for Standardization,
"Programming languages - C", 2011. "Programming languages - C", 2011.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Specifications: ABNF", STD 68, RFC 5234,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, 26 November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
19. Informative References 19. Informative References
[W3C.REC-xpath-19991116]
Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, 16 November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[Matroska] IETF, "Matroska Specifications", 2019, [Matroska] IETF, "Matroska Specifications", 2019,
<https://datatracker.ietf.org/doc/draft-ietf-cellar- <https://datatracker.ietf.org/doc/draft-ietf-cellar-
matroska/>. matroska/>.
[WebM] The WebM Project, "WebM Container Guidelines", November [WebM] The WebM Project, "WebM Container Guidelines", November
2017, <https://www.webmproject.org/docs/container/>. 2017, <https://www.webmproject.org/docs/container/>.
[W3C.REC-xpath-19991116]
Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, 16 November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
Authors' Addresses Authors' Addresses
Steve Lhomme Steve Lhomme
Email: slhomme@matroska.org Email: slhomme@matroska.org
Dave Rice Dave Rice
Email: dave@dericed.com Email: dave@dericed.com
 End of changes. 66 change blocks. 
237 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/