draft-ietf-cellar-ebml-03.txt   draft-ietf-cellar-ebml-04.txt 
cellar S. Lhomme cellar S. Lhomme
Internet-Draft Internet-Draft
Intended status: Standards Track D. Rice Intended status: Standards Track D. Rice
Expires: January 3, 2018 Expires: July 7, 2018
M. Bunkus M. Bunkus
July 2, 2017 January 3, 2018
Extensible Binary Meta Language Extensible Binary Meta Language
draft-ietf-cellar-ebml-03 draft-ietf-cellar-ebml-04
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 generalized file format for any type of data in a
hierarchical form. EBML is designed as a binary equivalent to XML hierarchical form. EBML is designed as a binary equivalent to XML
and uses a storage-efficient approach to build nested Elements with and uses a storage-efficient approach to build nested Elements with
identifiers, lengths, and values. Similar to how an XML Schema identifiers, lengths, and values. Similar to how an XML Schema
defines the structure and semantics of an XML Document, this document defines the structure and semantics of an XML Document, this document
defines how EBML Schemas are created to convey the semantics of an defines how 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 http://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 January 3, 2018. This Internet-Draft will expire on July 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 11 skipping to change at page 3, line 11
14.1.4. Attributes . . . . . . . . . . . . . . . . . . . . . 21 14.1.4. Attributes . . . . . . . . . . . . . . . . . . . . . 21
14.1.5. Element . . . . . . . . . . . . . . . . . . . . . . 25 14.1.5. Element . . . . . . . . . . . . . . . . . . . . . . 25
14.1.6. Attributes . . . . . . . . . . . . . . . . . . . . . 25 14.1.6. Attributes . . . . . . . . . . . . . . . . . . . . . 25
14.1.7. Element . . . . . . . . . . . . . . . . . . . . . . 26 14.1.7. Element . . . . . . . . . . . . . . . . . . . . . . 26
14.1.8. Element . . . . . . . . . . . . . . . . . . . . . . 26 14.1.8. Element . . . . . . . . . . . . . . . . . . . . . . 26
14.1.9. Attributes . . . . . . . . . . . . . . . . . . . . . 26 14.1.9. Attributes . . . . . . . . . . . . . . . . . . . . . 26
14.1.10. XML Schema for EBML Schema . . . . . . . . . . . . . 26 14.1.10. XML Schema for EBML Schema . . . . . . . . . . . . . 26
14.1.11. EBML Schema Example . . . . . . . . . . . . . . . . 28 14.1.11. EBML Schema Example . . . . . . . . . . . . . . . . 28
14.1.12. Identically Recurring Elements . . . . . . . . . . . 29 14.1.12. Identically Recurring Elements . . . . . . . . . . . 29
14.1.13. Expression of range . . . . . . . . . . . . . . . . 29 14.1.13. Expression of range . . . . . . . . . . . . . . . . 29
14.1.14. Textual expression of Floats . . . . . . . . . . . . 30 14.1.14. Textual expression of floats . . . . . . . . . . . . 30
14.1.15. Note on the Use of default attributes to define 14.1.15. Note on the use of default attributes to define
Mandatory EBML Elements . . . . . . . . . . . . . . 31 Mandatory EBML Elements . . . . . . . . . . . . . . 31
14.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 31 14.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 31
14.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 31 14.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 31
14.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 32 14.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 32
14.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 32 14.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 32
14.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 33 14.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 33
14.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 33 14.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 33
14.2.6. DocType Element . . . . . . . . . . . . . . . . . . 34 14.2.6. DocType Element . . . . . . . . . . . . . . . . . . 34
14.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 34 14.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 34
14.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 35 14.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 35
14.3. Global elements (used everywhere in the format) . . . . 35 14.3. Global Elements . . . . . . . . . . . . . . . . . . . . 35
14.3.1. Void Element . . . . . . . . . . . . . . . . . . . . 36 14.3.1. CRC-32 Element . . . . . . . . . . . . . . . . . . . 35
14.3.2. Void Element . . . . . . . . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. Normative References . . . . . . . . . . . . . . . . . . 36 15.1. Normative References . . . . . . . . . . . . . . . . . . 36
15.2. Informative References . . . . . . . . . . . . . . . . . 37 15.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
(such as containers for multimedia content) using an "EBML Schema". (such as containers for multimedia content) using an "EBML Schema".
The definition of the "EBML" format recognizes the idea behind HTML The definition of the "EBML" format recognizes the idea behind HTML
and XML as a good one: separate structure and semantics allowing the and XML as a good one: separate structure and semantics allowing the
same structural layer to be used with multiple, possibly widely same structural layer to be used with multiple, possibly widely
differing semantic layers. Except for the "EBML Header" and a few differing semantic layers. Except for the "EBML Header" and a few
global elements this specification does not define particular "EBML" "Global Elements" this specification does not define particular
format semantics; however this specification is intended to define "EBML" format semantics; however this specification is intended to
how other "EBML"-based formats can be defined. define how other "EBML"-based formats can be defined.
"EBML" uses a simple approach of building "Elements" upon three "EBML" uses a simple approach of building "Elements" upon three
pieces of data (tag, length, and value) as this approach is well pieces of data (tag, length, and value) as this approach is well
known, easy to parse, and allows selective data parsing. The "EBML" known, easy to parse, and allows selective data parsing. The "EBML"
structure additionally allows for hierarchical arrangement to support structure additionally allows for hierarchical arrangement to support
complex structural formats in an efficient manner. complex structural formats in an efficient manner.
2. Notation and Conventions 2. Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document defines specific terms in order to define the format This document defines specific terms in order to define the format
and application of "EBML". Specific terms are defined below: and application of "EBML". Specific terms are defined below:
"EBML": Extensible Binary Meta Language "EBML": Extensible Binary Meta Language
"EBML Document Type": An "EBML Document Type" is a name provided by "EBML Document Type": A name provided by an "EBML Schema" to
an "EBML Schema" for a particular implementation of "EBML" for a data designate a particular implementation of "EBML" for a data format
format (examples: matroska and webm). (e.g.: matroska and webm).
"EBML Schema": A standardized definition for the structure of an "EBML Schema": A standardized definition for the structure of an
"EBML Document Type". "EBML Document Type".
"EBML Document": An "EBML Document" is a datastream comprised of only "EBML Document": A datastream comprised of only two components, an
two components, an "EBML Header" and an "EBML Body". "EBML Header" and an "EBML Body".
"EBML Reader": An "EBML Reader" is a data parser that interprets the "EBML Reader": A data parser that interprets the semantics of an
semantics of an "EBML Document" and creates a way for programs to use "EBML Document" and creates a way for programs to use "EBML".
"EBML".
"EBML Stream": An "EBML Stream" is a file that consists of one or "EBML Stream": A file that consists of one or more "EBML Documents"
more "EBML Documents" that are concatenated together. that are concatenated together.
"EBML Header": The "EBML Header" is a declaration that provides "EBML Header": A declaration that provides processing instructions
processing instructions and identification of the "EBML Body". The and identification of the "EBML Body". The "EBML Header" may be
"EBML Header" may be considered as analogous to an XML Declaration considered as analogous to an XML Declaration [W3C.REC-xml-20081126]
[W3C.REC-xml-20081126] (see section 2.8 on Prolog and Document Type (see section 2.8 on Prolog and Document Type Declaration).
Declaration).
"EBML Body": All data of an "EBML Document" following the "EBML "EBML Body": All data of an "EBML Document" following the "EBML
Header" may be considered the "EBML Body". Header".
"Variable Size Integer": A compact variable-length binary value which "Variable Size Integer": A compact variable-length binary value which
defines its own length. defines its own length.
"VINT": Also known as "Variable Size Integer". "VINT": Also known as "Variable Size Integer".
"EBML Element": A foundation block of data that contains three parts: "EBML Element": A foundation block of data that contains three parts:
an "Element ID", an "Element Data Size", and "Element Data". an "Element ID", an "Element Data Size", and "Element Data".
"Element ID": The "Element ID" is a binary value, encoded as a "Element ID": The "Element ID" is a binary value, encoded as a
skipping to change at page 5, line 14 skipping to change at page 5, line 18
"EBML Class": A representation of the octet length of an "Element "EBML Class": A representation of the octet length of an "Element
ID". ID".
"Element Data Size": An expression, encoded as a "Variable Size "Element Data Size": An expression, encoded as a "Variable Size
Integer", of the length in octets of "Element Data". Integer", of the length in octets of "Element Data".
"VINTMAX": The maximum possible value that can be stored as "Element "VINTMAX": The maximum possible value that can be stored as "Element
Data Size". Data Size".
"Unknown-Sized Element": An Element with an unknown "Element Data "Unknown-Sized Element": An "Element" with an unknown "Element Data
Size". Size".
"Element Data": The value(s) of the "EBML Element" which is "Element Data": The value(s) of the "EBML Element" which is
identified by its "Element ID" and "Element Data Size". The form of identified by its "Element ID" and "Element Data Size". The form of
the "Element Data" is defined by this document and the corresponding the "Element Data" is defined by this document and the corresponding
"EBML Schema" of the Element's "EBML Document Type". "EBML Schema" of the Element's "EBML Document Type".
"Root Level": The starting level in the hierarchy of an "EBML "Root Level": The starting level in the hierarchy of an "EBML
Document". Document".
skipping to change at page 5, line 44 skipping to change at page 5, line 48
other "EBML Elements". other "EBML Elements".
"Child Element": A "Child Element" is a relative term to describe the "Child Element": A "Child Element" is a relative term to describe the
"EBML Elements" immediately contained within a "Master Element". "EBML Elements" immediately contained within a "Master Element".
"Parent Element": A relative term to describe the "Master Element" "Parent Element": A relative term to describe the "Master Element"
which contains a specified element. For any specified "EBML Element" which contains a specified element. For any specified "EBML Element"
that is not at "Root Level", the "Parent Element" refers to the that is not at "Root Level", the "Parent Element" refers to the
"Master Element" in which that "EBML Element" is contained. "Master Element" in which that "EBML Element" is contained.
"Descendant Element": A "Descendant Element" is a relative term to "Descendant Element": A relative term to describe any "EBML Elements"
describe any "EBML Elements" contained within a "Master Element", contained within a "Master Element", including any of the "Child
including any of the "Child Elements" of its "Child Elements", and so Elements" of its "Child Elements", and so on.
on.
"Void Element": A "Void Element" is an "Element" used to overwrite
damaged data or reserve space within a "Master Element" for later
use.
"Element Name": The official human-readable name of the "EBML "Element Name": The official human-readable name of the "EBML
Element". Element".
"Element Path": The hierarchy of "Parent Element" where the "EBML "Element Path": The hierarchy of "Parent Element" where the "EBML
Element" is expected to be found in the "EBML Body". Element" is expected to be found in the "EBML Body".
"Empty Element": An "Empty Element" is an "EBML Element" that has an "Empty Element": An "EBML Element" that has an "Element Data Size"
"Element Data Size" with all "VINT_DATA" bits set to zero which with all "VINT_DATA" bits set to zero, which indicates that the
indicates that the "Element Data" of the Element is zero octets in "Element Data" of the "Element" is zero octets in length.
length.
3. Security Considerations 3. Security Considerations
"EBML" itself does not offer any kind of security and does not "EBML" itself does not offer any kind of security and does not
provide confidentiality. "EBML" does not provide any kind of provide confidentiality. "EBML" does not provide any kind of
authorization. "EBML" only offers marginally useful and effective authorization. "EBML" only offers marginally useful and effective
data integrity options, such as CRC elements. data integrity options, such as CRC elements.
Even if the semantic layer offers any kind of encryption, "EBML" Even if the semantic layer offers any kind of encryption, "EBML"
itself could leak information at both the semantic layer (as declared itself could leak information at both the semantic layer (as declared
via the DocType element) and within the "EBML" structure (you can via the "DocType Element") and within the "EBML" structure (the
derive the presence of "EBML Elements" even with an unknown semantic presence of "EBML Elements" can be derived even with an unknown
layer with a heuristic approach; not without errors, of course, but semantic layer using a heuristic approach; not without errors, of
with a certain degree of confidence). course, but with a certain degree of confidence).
Attacks on an "EBML Reader" could include: Attacks on an "EBML Reader" could include:
o Invalid "Element IDs" that are longer than the limit stated in the o Invalid "Element IDs" that are longer than the limit stated in the
"EBMLMaxIDLength Element" of the "EBML Header". "EBMLMaxIDLength Element" of the "EBML Header".
o Invalid "Element IDs" that are not encoded in the shortest- o Invalid "Element IDs" that are not encoded in the shortest-
possible way. possible way.
o Invalid "Element IDs" comprised of reserved values. o Invalid "Element IDs" comprised of reserved values.
skipping to change at page 7, line 35 skipping to change at page 7, line 40
Element" that contain invalid "CRC-32 Elements". Element" that contain invalid "CRC-32 Elements".
o Use of "Void Elements". o Use of "Void Elements".
4. IANA Considerations 4. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
5. Structure 5. Structure
"EBML" uses a system of Elements to compose an "EBML Document". "EBML" uses a system of "Elements" to compose an "EBML Document".
"EBML Elements" incorporate three parts: an "Element ID", an "Element "EBML Elements" incorporate three parts: an "Element ID", an "Element
Data Size", and "Element Data". The "Element Data", which is Data Size", and "Element Data". The "Element Data", which is
described by the "Element ID", includes either binary data, one or described by the "Element ID", includes either binary data, one or
many other "EBML Elements", or both. many other "EBML Elements", or both.
6. Variable Size Integer 6. Variable Size Integer
The "Element ID" and "Element Data Size" are both encoded as a The "Element ID" and "Element Data Size" are both encoded as a
"Variable Size Integer", developed according to a UTF-8 like system. "Variable Size Integer", developed according to a UTF-8 like system.
The "Variable Size Integer" is composed of a "VINT_WIDTH", The "Variable Size Integer" is composed of a "VINT_WIDTH",
"VINT_MARKER", and "VINT_DATA", in that order. "Variable Size "VINT_MARKER", and "VINT_DATA", in that order. "Variable Size
Integers" SHALL left-pad the "VINT_DATA" value with zero bits so that Integers" MUST left-pad the "VINT_DATA" value with zero bits so that
the whole "Variable Size Integer" is octet-aligned. "Variable Size the whole "Variable Size Integer" is octet-aligned. "Variable Size
Integers" SHALL be referred to as "VINT" for shorthand. Integer" will be referred to as "VINT" for shorthand.
6.1. VINT_WIDTH 6.1. VINT_WIDTH
Each "Variable Size Integer" begins with a "VINT_WIDTH" which Each "Variable Size Integer" begins with a "VINT_WIDTH" which
consists of zero or many zero-value bits. The count of consecutive consists of zero or many zero-value bits. The count of consecutive
zero-values of the "VINT_WIDTH" plus one equals the length in octets zero-values of the "VINT_WIDTH" plus one equals the length in octets
of the "Variable Size Integer". For example, a "Variable Size of the "Variable Size Integer". For example, a "Variable Size
Integer" that starts with a "VINT_WIDTH" which contains zero Integer" that starts with a "VINT_WIDTH" which contains zero
consecutive zero-value bits is one octet in length and a "Variable consecutive zero-value bits is one octet in length and a "Variable
Size Integer" that starts with one consecutive zero-value bit is two Size Integer" that starts with one consecutive zero-value bit is two
octets in length. The "VINT_WIDTH" MUST only contain zero-value bits octets in length. The "VINT_WIDTH" MUST only contain zero-value bits
or be empty. or be empty.
Within the "EBML Header" the "VINT_WIDTH" MUST NOT exceed three bits Within the "EBML Header" the "VINT_WIDTH" MUST NOT exceed three bits
in length (meaning that the "Variable Size Integer" MUST NOT exceed in length (meaning that the "Variable Size Integer" MUST NOT exceed
four octets in length). Within the "EBML Body", when "VINTs" are four octets in length). Within the "EBML Body", when a "VINT" is
used to express an "Element ID", the maximum length allowed for the used to express an "Element ID", the maximum length allowed for the
"VINT_WIDTH" is one less than the value set in the "EBMLMaxIDLength "VINT_WIDTH" is one less than the value set in the "EBMLMaxIDLength
Element". Within the "EBML Body", when "VINTs" are used to express Element". Within the "EBML Body", when a "VINT" is used to express
an "Element Data Size", the maximum length allowed for the an "Element Data Size", the maximum length allowed for the
"VINT_WIDTH" is one less than the value set in the "EBMLMaxSizeLength "VINT_WIDTH" is one less than the value set in the "EBMLMaxSizeLength
Element". Element".
6.2. VINT_MARKER 6.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" MUST be one bit in length and "VINT_MARKER". The "VINT_MARKER" MUST be one bit in length and
contain a bit with a value of one. The first bit with a value of one contain a bit with a value of one. The first bit with a value of one
skipping to change at page 15, line 42 skipping to change at page 15, line 42
portions of an "EBML Document"); otherwise the use of "Null Octets" portions of an "EBML Document"); otherwise the use of "Null Octets"
within a "String Element" or "UTF-8 Element" is NOT RECOMMENDED. An within a "String Element" or "UTF-8 Element" is NOT RECOMMENDED. An
"EBML Reader" MUST consider the value of the "String Element" or "EBML Reader" MUST consider the value of the "String Element" or
"UTF-8 Element" to be terminated upon the first read "Null Octet" and "UTF-8 Element" to be terminated upon the first read "Null Octet" and
MUST ignore any data following the first "Null Octet" within that MUST ignore any data following the first "Null Octet" within that
"Element". A string value and a copy of that string value terminated "Element". A string value and a copy of that string value terminated
by one or more "Null Octets" are semantically equal. by one or more "Null Octets" are semantically equal.
The following table shows examples of semantics and validation for The following table shows examples of semantics and validation for
the use of "Null Octets". Values to represent "Stored Values" and the use of "Null Octets". Values to represent "Stored Values" and
the "Semantic Meaning" as represented as hexidecimal values. the "Semantic Meaning" as represented as hexadecimal values.
+---------------------+---------------------+ +---------------------+---------------------+
| Stored Value | Semantic Meaning | | Stored Value | Semantic Meaning |
+---------------------+---------------------+ +---------------------+---------------------+
| 0x65 0x62 0x6d 0x6c | 0x65 0x62 0x6d 0x6c | | 0x65 0x62 0x6d 0x6c | 0x65 0x62 0x6d 0x6c |
| 0x65 0x62 0x00 0x6c | 0x65 0x62 | | 0x65 0x62 0x00 0x6c | 0x65 0x62 |
| 0x65 0x62 0x00 0x00 | 0x65 0x62 | | 0x65 0x62 0x00 0x00 | 0x65 0x62 |
| 0x65 0x62 | 0x65 0x62 | | 0x65 0x62 | 0x65 0x62 |
+---------------------+---------------------+ +---------------------+---------------------+
skipping to change at page 17, line 12 skipping to change at page 17, line 12
Note that if the "Element Data" length needs to be rewritten as Note that if the "Element Data" length needs to be rewritten as
shortened by one octet and the "Element Data Size" could be rewritten shortened by one octet and the "Element Data Size" could be rewritten
as a shorter "VINT" then it is RECOMMENDED to rewrite the "Element as a shorter "VINT" then it is RECOMMENDED to rewrite the "Element
Data Size" as one octet shorter, shorten the "Element Data" by one Data Size" as one octet shorter, shorten the "Element Data" by one
octet, and follow that "Element" with a "Void Element". For example, octet, and follow that "Element" with a "Void Element". For example,
the following table depicts a "String Element" that stores an the following table depicts a "String Element" that stores an
"Element ID" (3 octets), "Element Data Size" (2 octets, but could be "Element ID" (3 octets), "Element Data Size" (2 octets, but could be
rewritten in one octet), and "Element Data" (3 octets). If the rewritten in one octet), and "Element Data" (3 octets). If the
"Element Data" is to be rewritten to a two octet length, then another "Element Data" is to be rewritten to a two octet length, then another
octet can be taken from "Element Data Size" so that there is enough octet can be taken from "Element Data Size" so that there is enough
space to add a two octent "Void Element". space to add a two octet "Void Element".
+--------+------------+-----------------+-------------+-------------+ +--------+------------+-----------------+-------------+-------------+
| Status | Element ID | Element Data | Element | Void | | Status | Element ID | Element Data | Element | Void |
| | | Size | Data | Element | | | | Size | Data | Element |
+--------+------------+-----------------+-------------+-------------+ +--------+------------+-----------------+-------------+-------------+
| Before | 0x3B4040 | 0x4003 | 0x6d6b76 | | | Before | 0x3B4040 | 0x4003 | 0x6d6b76 | |
| After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 | | After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 |
+--------+------------+-----------------+-------------+-------------+ +--------+------------+-----------------+-------------+-------------+
11.1.3. Terminating Element Data 11.1.3. Terminating Element Data
skipping to change at page 19, line 32 skipping to change at page 19, line 32
with one or many "EBML Document Types". An "EBML Schema" must be with one or many "EBML Document Types". An "EBML Schema" must be
expressed as well-formed XML. An "EBML Document Type" is identified expressed as well-formed XML. An "EBML Document Type" is identified
by a string stored within the "EBML Header" in the "DocType Element"; by a string stored within the "EBML Header" in the "DocType Element";
for example "matroska" or "webm" (see Section 14.2.6). The "DocType" for example "matroska" or "webm" (see Section 14.2.6). The "DocType"
value for an "EBML Document Type" SHOULD be unique and persistent. value for an "EBML Document Type" SHOULD be unique and persistent.
An "EBML Schema" MUST declare exactly one "EBML Element" at "Root An "EBML Schema" MUST declare exactly one "EBML Element" at "Root
Level" (referred to as the "Root Element") that MUST occur exactly Level" (referred to as the "Root Element") that MUST occur exactly
once within an "EBML Document". The "Void Element" MAY also occur at once within an "EBML Document". The "Void Element" MAY also occur at
"Root Level" but is not considered to be "Root Elements" (see "Root Level" but is not considered to be "Root Elements" (see
Section 14.3.1). Section 14.3.2).
The "EBML Schema" MUST document all Elements of the "EBML Body". The The "EBML Schema" MUST document all Elements of the "EBML Body". The
"EBML Schema" does not document "Global Elements" that are defined by "EBML Schema" does not document "Global Elements" that are defined by
this document (namely the "Void Element" and the "CRC-32 Element"). this document (namely the "Void Element" and the "CRC-32 Element").
An "EBML Schema" MAY constrain the use of "EBML Header Elements" (see An "EBML Schema" MAY constrain the use of "EBML Header Elements" (see
Section 14.2) by adding or constraining that Element's "range" Section 14.2) by adding or constraining that Element's "range"
attribute. For example, an "EBML Schema" MAY constrain the attribute. For example, an "EBML Schema" MAY constrain the
"EBMLMaxSizeLength" to a maximum value of "8" or MAY constain the "EBMLMaxSizeLength" to a maximum value of "8" or MAY constrain the
"EBMLVersion" to only support a value of "1". If an "EBML Schema" "EBMLVersion" to only support a value of "1". If an "EBML Schema"
adopts the "EBML Header Element" as-is, then it is not REQUIRED to adopts the "EBML Header Element" as-is, then it is not REQUIRED to
document that Element within the "EBML Schema". If an "EBML Schema" document that Element within the "EBML Schema". If an "EBML Schema"
constrains the range of an "EBML Header Element", then that "Element" constrains the range of an "EBML Header Element", then that "Element"
MUST be documented within an "<element>" node of the "EBML Schema". MUST be documented within an "<element>" node of the "EBML Schema".
This document provides an example of an "EBML Schema", see This document provides an example of an "EBML Schema", see
Section 14.1.11. Section 14.1.11.
14.1.1. Element 14.1.1. Element
skipping to change at page 22, line 47 skipping to change at page 22, line 47
"EBMLMaxOccurrence" is not present then that "EBML Element" is "EBMLMaxOccurrence" is not present then that "EBML Element" is
considered to have no maximum occurrence. The semantic meaning of considered to have no maximum occurrence. The semantic meaning of
"EBMLMaxOccurrence" within an "EBML Schema path" is considered "EBMLMaxOccurrence" within an "EBML Schema path" is considered
analogous to the meaning of "maxOccurs" within an "XML Schema". analogous to the meaning of "maxOccurs" within an "XML Schema".
The "VariableParentOccurrence" part is interpreted as an ABNF The "VariableParentOccurrence" part is interpreted as an ABNF
Variable Repetition. The repetition amounts correspond to the amount Variable Repetition. The repetition amounts correspond to the amount
of unspecified "Parent Element" levels there can be between the of unspecified "Parent Element" levels there can be between the
"EBMLFixedParent" and the actual "EBMLElementPath". "EBMLFixedParent" and the actual "EBMLElementPath".
If the path contains a "EBMLPathAtomRecursive" part, the "EBML If the path contains an "EBMLPathAtomRecursive" part, the "EBML
Element" can occur within itself recursively (see the Element" can occur within itself recursively (see the
Section 14.1.4.11). Section 14.1.4.11).
14.1.4.3. id 14.1.4.3. 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 hexadecimal notation prefixed by a "0x" that is read and stored in
big-endian order. To reduce the risk of false positives while big-endian order. To reduce the risk of false positives while
parsing "EBML Streams", the "Element IDs" of the "Root Element" and parsing "EBML Streams", the "Element IDs" of the "Root Element" and
"Top-Level Elements" SHOULD be at least 4 octets in length. "Element "Top-Level Elements" SHOULD be at least 4 octets in length. "Element
skipping to change at page 24, line 21 skipping to change at page 24, line 21
integer or a range (see Section 14.1.13) that consists of only non- integer or a range (see Section 14.1.13) that consists of only non-
negative integers and valid operators. negative integers and valid operators.
The "size" attribute is OPTIONAL. If the "size" attribute is not The "size" attribute is OPTIONAL. If the "size" attribute is not
present for that "EBML Element" then that "EBML Element" is only present for that "EBML Element" then that "EBML Element" is only
limited in size by the definition of the associated "EBML Element limited in size by the definition of the associated "EBML Element
Type". Type".
14.1.4.8. default 14.1.4.8. default
If an Element is mandatory (has a "EBMLMinOccurrence" value greater If an "Element" is mandatory (has a "EBMLMinOccurrence" value greater
than zero) but not written within its "Parent Element" or stored as than zero) but not written within its "Parent Element" or stored as
an "Empty Element", then the "EBML Reader" of the "EBML Document" an "Empty Element", then the "EBML Reader" of the "EBML Document"
MUST semantically interpret the "EBML Element" as present with this MUST semantically interpret the "EBML Element" as present with this
specified default value for the "EBML Element". "EBML Elements" that specified default value for the "EBML Element". "EBML Elements" that
are "Master Elements" MUST NOT declare a "default" value. "EBML are "Master Elements" MUST NOT declare a "default" value. "EBML
Elements" with a "minOccurs" value greater than 1 MUST NOT declare a Elements" with a "minOccurs" value greater than 1 MUST NOT declare a
"default" value. "default" value.
The "default" attribute is OPTIONAL. The "default" attribute is OPTIONAL.
skipping to change at page 25, line 14 skipping to change at page 25, line 14
14.1.4.11. recursive 14.1.4.11. recursive
A boolean to express if an "EBML Element" MAY be stored recursively. A boolean to express if an "EBML Element" MAY be stored recursively.
In this case the "EBML Element" MAY be stored within another "EBML In this case the "EBML Element" MAY be stored within another "EBML
Element" that has the same "Element ID". Which itself can be stored Element" that has the same "Element ID". Which itself can be stored
in an "EBML Element" that has the same "Element ID", and so on. in an "EBML Element" that has the same "Element ID", and so on.
"EBML Elements" that are not "Master Elements" MUST NOT set "EBML Elements" that are not "Master Elements" MUST NOT set
"recursive" to true. "recursive" to true.
If the "path" contains a "EBMLPathAtomRecursive" part then the If the "path" contains an "EBMLPathAtomRecursive" part then the
"recursive" value MUST be true and false otherwise. "recursive" value MUST be true and false otherwise.
The "recursive" attribute is OPTIONAL. If the "recursive" attribute The "recursive" attribute is OPTIONAL. If the "recursive" attribute
is not present then the "EBML Element" MUST NOT be used recursively. is not present then the "EBML Element" MUST NOT be used recursively.
14.1.4.12. minver 14.1.4.12. minver
The "minver" (minimum version) attribute stores a non-negative The "minver" (minimum version) attribute stores a non-negative
integer that represents the first version of the "docType" to support integer that represents the first version of the "docType" to support
the "EBML Element". the "EBML Element".
The "minver" attribute is OPTIONAL. If the "minver" attribute is not The "minver" attribute is OPTIONAL. If the "minver" attribute is not
present then the "EBML Element" has a minimum version of "1". present, then the "EBML Element" has a minimum version of "1".
14.1.4.13. maxver 14.1.4.13. maxver
The "maxver" (maximum version) attribute stores a non-negative The "maxver" (maximum version) attribute stores a non-negative
integer that represents the last or most recent version of the integer that represents the last or most recent version of the
"docType" to support the element. "maxver" MUST be greater than or "docType" to support the element. "maxver" MUST be greater than or
equal to "minver". equal to "minver".
The "maxver" attribute is OPTIONAL. If the "maxver" attribute is not The "maxver" attribute is OPTIONAL. If the "maxver" attribute is not
present then the "EBML Element" has a maximum version equal to the present then the "EBML Element" has a maximum version equal to the
skipping to change at page 26, line 24 skipping to change at page 26, line 24
14.1.7. Element 14.1.7. Element
The "<restriction>" element provides information about restrictions The "<restriction>" element provides information about restrictions
to the allowable values for the "EBML Element" which are listed in to the allowable values for the "EBML Element" which are listed in
"<enum>" elements. "<enum>" elements.
14.1.8. Element 14.1.8. Element
The "<enum>" element stores a list of values allowed for storage in The "<enum>" element stores a list of values allowed for storage in
the "EBML Element". The values MUST match the "type" of the "EBML the "EBML Element". The values MUST match the "type" of the "EBML
Element" (for example "<enum value="Yes">" can not be a valid value Element" (for example "<enum value="Yes">" cannot be a valid value
for a "EBML Element" that is defined as an unsigned integer). An for a "EBML Element" that is defined as an unsigned integer). An
"<enum>" element MAY also store "<documentation>" elements to further "<enum>" element MAY also store "<documentation>" elements to further
describe the "<enum>". describe the "<enum>".
14.1.9. Attributes 14.1.9. Attributes
14.1.9.1. label 14.1.9.1. label
The "label" provides a concise expression for human consumption that The "label" provides a concise expression for human consumption that
describes what the "value" of the "<enum>" represents. describes what the "value" of the "<enum>" represents.
skipping to change at page 30, line 20 skipping to change at page 30, line 20
o "<=x" where "x" is an integer or float, meaning that the value o "<=x" where "x" is an integer or float, meaning that the value
MUST be less than or equal to "x". MUST be less than or equal to "x".
o "x" where "x" is an integer or float, meaning that the value MUST o "x" where "x" is an integer or float, meaning that the value MUST
be equal "x". be equal "x".
The "range" may use the prefix "not" to indicate that the expressed The "range" may use the prefix "not" to indicate that the expressed
range is negated. Please also see Section 14.1.14. range is negated. Please also see Section 14.1.14.
14.1.14. Textual expression of Floats 14.1.14. Textual expression of floats
When a float value is represented textually in an "EBML Schema", such When a float value is represented textually in an "EBML Schema", such
as within a "default" or "range" value, the float values MUST be as within a "default" or "range" value, the float values MUST be
expressed as Hexadecimal Floating-Point Constants as defined in the expressed as Hexadecimal Floating-Point Constants as defined in the
C11 standard [ISO.9899.2011] (see section 6.4.4.2 on Floating C11 standard [ISO.9899.2011] (see section 6.4.4.2 on Floating
Constants). The following table provides examples of expressions of Constants). The following table provides examples of expressions of
float ranges. float ranges.
+-------------------+-----------------------------------------+ +-------------------+-----------------------------------------+
| as decimal | as Hexadecimal Floating-Point Constants | | as decimal | as Hexadecimal Floating-Point Constants |
skipping to change at page 31, line 5 skipping to change at page 31, line 5
maximum value permitted by the range. Hexadecimal Floating-Point maximum value permitted by the range. Hexadecimal Floating-Point
Constants also use a "-" (hyphen) when indicating a negative binary Constants also use a "-" (hyphen) when indicating a negative binary
power. Within a float range, when a "-" (hyphen) is immediately power. Within a float range, when a "-" (hyphen) is immediately
preceded by a letter "p", then the "-" (hyphen) is a part of the preceded by a letter "p", then the "-" (hyphen) is a part of the
Hexadecimal Floating-Point Constant which notes negative binary Hexadecimal Floating-Point Constant which notes negative binary
power. Within a float range, when a "-" (hyphen) is not immediately power. Within a float range, when a "-" (hyphen) is not immediately
preceded by a letter "p", then the "-" (hyphen) represents the preceded by a letter "p", then the "-" (hyphen) represents the
separator between the minimal and maximum value permitted by the separator between the minimal and maximum value permitted by the
range. range.
14.1.15. Note on the Use of default attributes to define Mandatory EBML 14.1.15. Note on the use of default attributes to define Mandatory EBML
Elements Elements
If a "Mandatory EBML Element" has a default value declared by an If a "Mandatory EBML Element" has a default value declared by an
"EBML Schema" and the value of the "EBML Element" is equal to the "EBML Schema" and the value of the "EBML Element" is equal to the
declared default value then that "EBML Element" is not required to be declared default value then that "EBML Element" is not required to be
present within the "EBML Document" if its "Parent Element" is present within the "EBML Document" if its "Parent Element" is
present. In this case, the default value of the "Mandatory EBML present. In this case, the default value of the "Mandatory EBML
Element" MUST be interpreted by the "EBML Reader" although the "EBML Element" MUST be interpreted by the "EBML Reader" although the "EBML
Element" is not present within its "Parent Element". Element" is not present within its "Parent Element".
skipping to change at page 35, line 26 skipping to change at page 35, line 26
default: 1 default: 1
type: Unsigned Integer type: Unsigned Integer
description: The minimum "DocType" version an "EBML Reader" has to description: The minimum "DocType" version an "EBML Reader" has to
support to read this "EBML Document". The value of the support to read this "EBML Document". The value of the
"DocTypeReadVersion Element" MUST be less than or equal to the value "DocTypeReadVersion Element" MUST be less than or equal to the value
of the "DocTypeVersion Element". of the "DocTypeVersion Element".
14.3. Global elements (used everywhere in the format) 14.3. Global Elements
EBML defines these "Global Elements" which MAY be stored within any
"Master Element" of an "EBML Document" as defined by their "Element
Path".
14.3.1. CRC-32 Element
name: CRC-32 name: CRC-32
path: "*1((1*\)\CRC-32)" path: "*1((1*\)\CRC-32)"
id: "0xBF" id: "0xBF"
minOccurs: 0 minOccurs: 0
maxOccurs: 1 maxOccurs: 1
skipping to change at page 36, line 5 skipping to change at page 36, line 11
stored except for the "CRC-32 Element" itself. When the "CRC-32 stored except for the "CRC-32 Element" itself. When the "CRC-32
Element" is present, the "CRC-32 Element" MUST be the first ordered Element" is present, the "CRC-32 Element" MUST be the first ordered
"EBML Element" within its "Parent Element" for easier reading. All "EBML Element" within its "Parent Element" for easier reading. All
"Top-Level Elements" of an "EBML Document" that are "Master Elements" "Top-Level Elements" of an "EBML Document" that are "Master Elements"
SHOULD include a "CRC-32 Element" as a "Child Element". The CRC in SHOULD include a "CRC-32 Element" as a "Child Element". The CRC in
use is the IEEE-CRC-32 algorithm as used in the [ISO.3309.1979] use is the IEEE-CRC-32 algorithm as used in the [ISO.3309.1979]
standard and in section 8.1.1.6.2 of [ITU.V42.1994], with initial standard and in section 8.1.1.6.2 of [ITU.V42.1994], with initial
value of "0xFFFFFFFF". The CRC value MUST be computed on a little value of "0xFFFFFFFF". The CRC value MUST be computed on a little
endian bitstream and MUST use little endian storage. endian bitstream and MUST use little endian storage.
14.3.1. Void Element 14.3.2. Void Element
name: Void name: Void
path: "*((*\)\Void)" path: "*((*\)\Void)"
id: "0xEC" id: "0xEC"
minOccurs: 0 minOccurs: 0
type: Binary type: Binary
skipping to change at page 36, line 46 skipping to change at page 37, line 7
International Organization for Standardization, International Organization for Standardization,
"Programming languages - C", ISO Standard 9899, 2011. "Programming languages - C", ISO Standard 9899, 2011.
[ITU.V42.1994] [ITU.V42.1994]
International Telecommunications Union, "Error-correcting International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994. Conversion", ITU-T Recommendation V.42, 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,
<http://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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, <http://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[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,
<http://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
15.2. Informative References 15.2. Informative References
 End of changes. 46 change blocks. 
69 lines changed or deleted 76 lines changed or added

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