idnits 2.17.1 draft-ietf-cellar-ebml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 18 instances of too long lines in the document, the longest one being 113 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2017) is 2613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EBMLParentPath' is mentioned on line 836, but not defined == Missing Reference: 'EBMLMinOccurrence' is mentioned on line 847, but not defined == Missing Reference: 'EBMLMaxOccurrence' is mentioned on line 847, but not defined == Missing Reference: 'PathMinOccurrence' is mentioned on line 850, but not defined == Missing Reference: 'PathMaxOccurrence' is mentioned on line 850, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.V42.1994' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 cellar S. Lhomme 3 Internet-Draft 4 Intended status: Standards Track D. Rice 5 Expires: August 30, 2017 6 M. Bunkus 7 February 26, 2017 9 Extensible Binary Meta Language 10 draft-ietf-cellar-ebml-02 12 Abstract 14 This document defines the Extensible Binary Meta Language (EBML) 15 format as a generalized file format for any type of data in a 16 hierarchical form. EBML is designed as a binary equivalent to XML 17 and uses a storage-efficient approach to build nested Elements with 18 identifiers, lengths, and values. Similar to how an XML Schema 19 defines the structure and semantics of an XML Document, this document 20 defines how EBML Schemas are created to convey the semantics of an 21 EBML Document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 30, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 3 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 4. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Variable Size Integer . . . . . . . . . . . . . . . . . . . . 7 62 5.1. VINT_WIDTH . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. VINT_MARKER . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3. VINT_DATA . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.4. VINT Examples . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Element ID . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. Element Data Size . . . . . . . . . . . . . . . . . . . . . . 10 68 8. EBML Element Types . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Signed Integer Element . . . . . . . . . . . . . . . . . 13 70 8.2. Unsigned Integer Element . . . . . . . . . . . . . . . . 13 71 8.3. Float Element . . . . . . . . . . . . . . . . . . . . . . 13 72 8.4. String Element . . . . . . . . . . . . . . . . . . . . . 13 73 8.5. UTF-8 Element . . . . . . . . . . . . . . . . . . . . . . 14 74 8.6. Date Element . . . . . . . . . . . . . . . . . . . . . . 14 75 8.7. Master Element . . . . . . . . . . . . . . . . . . . . . 14 76 8.8. Binary Element . . . . . . . . . . . . . . . . . . . . . 15 77 9. EBML Document . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. EBML Header . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11. Elements semantic . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. EBML Schema . . . . . . . . . . . . . . . . . . . . . . 16 83 11.1.1. Element . . . . . . . . . . . . . . . . . . . . . . 17 84 11.1.2. Attributes . . . . . . . . . . . . . . . . . . . . . 17 85 11.1.3. Element . . . . . . . . . . . . . . . . . . . . . . 17 86 11.1.4. Attributes . . . . . . . . . . . . . . . . . . . . . 18 87 11.1.5. Element . . . . . . . . . . . . . . . . . . . . . . 22 88 11.1.6. Attributes . . . . . . . . . . . . . . . . . . . . . 22 89 11.1.7. Element . . . . . . . . . . . . . . . . . . . . . . 23 90 11.1.8. Element . . . . . . . . . . . . . . . . . . . . . . 23 91 11.1.9. Attributes . . . . . . . . . . . . . . . . . . . . . 23 92 11.1.10. XML Schema for EBML Schema . . . . . . . . . . . . . 23 93 11.1.11. EBML Schema Example . . . . . . . . . . . . . . . . 25 94 11.1.12. Identically Recurring Elements . . . . . . . . . . . 25 95 11.1.13. Expression of range . . . . . . . . . . . . . . . . 26 96 11.1.14. Textual expression of Floats . . . . . . . . . . . . 26 97 11.1.15. Note on the Use of default attributes to define 98 Mandatory EBML Elements . . . . . . . . . . . . . . 27 99 11.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 28 100 11.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 28 101 11.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 28 102 11.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 29 103 11.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 29 104 11.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 30 105 11.2.6. DocType Element . . . . . . . . . . . . . . . . . . 30 106 11.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 31 107 11.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 31 108 11.3. Global elements (used everywhere in the format) . . . . 31 109 11.3.1. Void Element . . . . . . . . . . . . . . . . . . . . 32 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 112 12.2. Informative References . . . . . . . . . . . . . . . . . 34 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 115 1. Introduction 117 "EBML", short for Extensible Binary Meta Language, specifies a binary 118 and octet (byte) aligned format inspired by the principle of XML (a 119 framework for structuring data). 121 The goal of this document is to define a generic, binary, space- 122 efficient format that can be used to define more complex formats 123 (such as containers for multimedia content) using an "EBML Schema". 124 The definition of the "EBML" format recognizes the idea behind HTML 125 and XML as a good one: separate structure and semantics allowing the 126 same structural layer to be used with multiple, possibly widely 127 differing semantic layers. Except for the "EBML Header" and a few 128 global elements this specification does not define particular "EBML" 129 format semantics; however this specification is intended to define 130 how other "EBML"-based formats can be defined. 132 "EBML" uses a simple approach of building "Elements" upon three 133 pieces of data (tag, length, and value) as this approach is well 134 known, easy to parse, and allows selective data parsing. The "EBML" 135 structure additionally allows for hierarchical arrangement to support 136 complex structural formats in an efficient manner. 138 2. Notation and Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 This document defines specific terms in order to define the format 145 and application of "EBML". Specific terms are defined below: 147 "Child Element": A "Child Element" is a relative term to describe the 148 "EBML Elements" immediately contained within a "Master Element". 150 "Descendant Element": A "Descendant Element" is a relative term to 151 describe any "EBML Elements" contained within a "Master Element", 152 including any of the "Child Elements" of its "Child Elements", and so 153 on. 155 "EBML": Extensible Binary Meta Language 157 "Element Data": The value(s) of the "EBML Element" which is 158 identified by its "Element ID" and "Element Data Size". The form of 159 the "Element Data" is defined by this document and the corresponding 160 "EBML Schema" of the Element's "EBML Document Type". 162 "Element Data Size": An expression, encoded as a "Variable Size 163 Integer", of the length in octets of "Element Data". 165 "EBML Body": All data of an "EBML Document" following the "EBML 166 Header" may be considered the "EBML Body". 168 "EBML Class": A representation of the octet length of an "Element 169 ID". 171 "EBML Document": An "EBML Document" is a datastream comprised of only 172 two components, an "EBML Header" and an "EBML Body". 174 "EBML Document Type": An "EBML Document Type" is a name provided by 175 an "EBML Schema" for a particular implementation of "EBML" for a data 176 format (examples: matroska and webm). 178 "EBML Element": A foundation block of data that contains three parts: 179 an "Element ID", an "Element Data Size", and "Element Data". 181 "EBML Header": The "EBML Header" is a declaration that provides 182 processing instructions and identification of the "EBML Body". The 183 "EBML Header" may be considered as analogous to an XML Declaration 184 [W3C.REC-xml-20081126] (see section 2.8 on Prolog and Document Type 185 Declaration). 187 "EBML Reader": An "EBML Reader" is a data parser that interprets the 188 semantics of an "EBML Document" and creates a way for programs to use 189 "EBML". 191 "EBML Schema": A standardized definition for the structure of an 192 "EBML Document Type". 194 "EBML Stream": An "EBML Stream" is a file that consists of one or 195 more "EBML Documents" that are concatenated together. 197 "Element ID": The "Element ID" is a binary value, encoded as a 198 "Variable Size Integer", used to uniquely identify a defined "EBML 199 Element" within a specific "EBML Schema". 201 "Element Name": The official human-readable name of the "EBML 202 Element". 204 "Element Path": The hierarchy of "Parent Element" where the "EBML 205 Element" is expected to be found in the "EBML Body". 207 "Empty Element": An "Empty Element" is an "EBML Element" that has an 208 "Element Data Size" with all "VINT_DATA" bits set to zero which 209 indicates that the "Element Data" of the Element is zero octets in 210 length. 212 "Master Element": The "Master Element" contains zero, one, or many 213 other "EBML Elements". 215 "Parent Element": A relative term to describe the "Master Element" 216 which contains a specified element. For any specified "EBML Element" 217 that is not at "Root Level", the "Parent Element" refers to the 218 "Master Element" in which that "EBML Element" is contained. 220 "Root Element": A mandatory, non-repeating "EBML Element" which 221 occurs at the top level of the path hierarchy within an "EBML Body" 222 and contains all other "EBML Elements" of the "EBML Body", excepting 223 optional "Void Elements". 225 "Root Level": The starting level in the hierarchy of an "EBML 226 Document". 228 "Top-Level Element": An "EBML Element" defined to only occur as a 229 "Child Element" of the "Root Element". 231 "Unknown-Sized Element": An Element with an unknown "Element Data 232 Size". 234 "Variable Size Integer": A compact variable-length binary value which 235 defines its own length. 237 "VINT": Also known as "Variable Size Integer". 239 "VINTMAX": The maximum possible value that can be stored as "Element 240 Data Size". 242 3. Security Considerations 244 "EBML" itself does not offer any kind of security and does not 245 provide confidentiality. "EBML" does not provide any kind of 246 authorization. "EBML" only offers marginally useful and effective 247 data integrity options, such as CRC elements. 249 Even if the semantic layer offers any kind of encryption, "EBML" 250 itself could leak information at both the semantic layer (as declared 251 via the DocType element) and within the "EBML" structure (you can 252 derive the presence of "EBML Elements" even with an unknown semantic 253 layer with a heuristic approach; not without errors, of course, but 254 with a certain degree of confidence). 256 Attacks on an "EBML Reader" could include: 258 o Invalid "Element IDs" that are longer than the limit stated in the 259 "EBMLMaxIDLength Element" of the "EBML Header". 261 o Invalid "Element IDs" that are not encoded in the shortest- 262 possible way. 264 o Invalid "Element IDs" comprised of reserved values. 266 o Invalid "Element Data Size" values that are longer than the limit 267 stated in the "EBMLMaxSizeLength Element" of the "EBML Header". 269 o Invalid "Element Data Size" values (e.g. extending the length of 270 the "EBML Element" beyond the scope of the "Parent Element"; 271 possibly triggering access-out-of-bounds issues). 273 o Very high lengths in order to force out-of-memory situations 274 resulting in a denial of service, access-out-of-bounds issues etc. 276 o Missing "EBML Elements" that are mandatory and have no declared 277 default value. 279 o Usage of "0x00" octets in "EBML Elements" with a string type. 281 o Usage of invalid UTF-8 encoding in "EBML Elements" of UTF-8 type 282 (e.g. in order to trigger access-out-of-bounds or buffer overflow 283 issues). 285 o Usage of invalid data in "EBML Elements" with a date type. 287 Side channel attacks could exploit: 289 o The semantic equivalence of the same string stored in a "String 290 Element" or "UTF-8 Element" with and without zero-bit padding. 292 o The semantic equivalence of "VINT_DATA" within "Element Data Size" 293 with to different lengths due to left-padding zero bits. 295 o Data contained within a "Master Element" which is not itself part 296 of an "EBML Element". 298 o Extraneous copies of "Identically Recurring Element". 300 o Copies of "Identically Recurring Element" within a "Parent 301 Element" that contain invalid "CRC-32 Elements". 303 o Use of "Void Elements". 305 4. Structure 307 "EBML" uses a system of Elements to compose an "EBML Document". 308 "EBML Elements" incorporate three parts: an "Element ID", an "Element 309 Data Size", and "Element Data". The "Element Data", which is 310 described by the "Element ID", includes either binary data, one or 311 many other "EBML Elements", or both. 313 5. Variable Size Integer 315 The "Element ID" and "Element Data Size" are both encoded as a 316 "Variable Size Integer", developed according to a UTF-8 like system. 317 The "Variable Size Integer" is composed of a "VINT_WIDTH", 318 "VINT_MARKER", and "VINT_DATA", in that order. "Variable Size 319 Integers" SHALL left-pad the "VINT_DATA" value with zero bits so that 320 the whole "Variable Size Integer" is octet-aligned. "Variable Size 321 Integers" SHALL be referred to as "VINT" for shorthand. 323 5.1. VINT_WIDTH 325 Each "Variable Size Integer" begins with a "VINT_WIDTH" which 326 consists of zero or many zero-value bits. The count of consecutive 327 zero-values of the "VINT_WIDTH" plus one equals the length in octets 328 of the "Variable Size Integer". For example, a "Variable Size 329 Integer" that starts with a "VINT_WIDTH" which contains zero 330 consecutive zero-value bits is one octet in length and a "Variable 331 Size Integer" that starts with one consecutive zero-value bit is two 332 octets in length. The "VINT_WIDTH" MUST only contain zero-value bits 333 or be empty. 335 Within the "EBML Header" the "VINT_WIDTH" MUST NOT exceed three bits 336 in length (meaning that the "Variable Size Integer" MUST NOT exceed 337 four octets in length). Within the "EBML Body", when "VINTs" are 338 used to express an "Element ID", the maximum length allowed for the 339 "VINT_WIDTH" is one less than the value set in the "EBMLMaxIDLength 340 Element". Within the "EBML Body", when "VINTs" are used to express 341 an "Element Data Size", the maximum length allowed for the 342 "VINT_WIDTH" is one less than the value set in the "EBMLMaxSizeLength 343 Element". 345 5.2. VINT_MARKER 347 The "VINT_MARKER" serves as a separator between the "VINT_WIDTH" and 348 "VINT_DATA". Each "Variable Size Integer" MUST contain exactly one 349 "VINT_MARKER". The "VINT_MARKER" MUST be one bit in length and 350 contain a bit with a value of one. The first bit with a value of one 351 within the "Variable Size Integer" is the "VINT_MARKER". 353 5.3. VINT_DATA 355 The "VINT_DATA" portion of the "Variable Size Integer" includes all 356 data that follows (but not including) the "VINT_MARKER" until end of 357 the "Variable Size Integer" whose length is derived from the 358 "VINT_WIDTH". The bits required for the "VINT_WIDTH" and the 359 "VINT_MARKER" combined use one out of eight bits of the total length 360 of the "Variable Size Integer". Thus a "Variable Size Integer" of 1 361 octet length supplies 7 bits for "VINT_DATA", a 2 octet length 362 supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21 363 bits for "VINT_DATA". If the number of bits required for "VINT_DATA" 364 are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be 365 zero-padded to the left to a size that fits. The "VINT_DATA" value 366 MUST be expressed as a big-endian unsigned integer. 368 5.4. VINT Examples 370 This table shows examples of "Variable Size Integers" with lengths 371 from 1 to 5 octets. The Size column refers to the size of the 372 "VINT_DATA" in bits. The Representation column depicts a binary 373 expression of "Variable Size Integers" where "VINT_WIDTH" is depicted 374 by '0', the "VINT_MARKER" as '1', and the "VINT_DATA" as 'x'. 376 +-------------+------+----------------------------------------------+ 377 | Octet | Size | Representation | 378 | Length | | | 379 +-------------+------+----------------------------------------------+ 380 | 1 | 2^7 | 1xxx xxxx | 381 | 2 | 2^14 | 01xx xxxx xxxx xxxx | 382 | 3 | 2^21 | 001x xxxx xxxx xxxx xxxx xxxx | 383 | 4 | 2^28 | 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 384 | 5 | 2^35 | 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 385 | | | xxxx | 386 +-------------+------+----------------------------------------------+ 388 Data encoded as a "Variable Size Integer" MAY be rendered at octet 389 lengths larger than needed to store the data. In this table a binary 390 value of "0b10" is shown encoded as different "Variable Size 391 Integers" with lengths from one octet to four octet. All four 392 encoded examples have identical semantic meaning though the 393 "VINT_WIDTH" and the padding of the "VINT_DATA" vary. 395 +--------------+--------------+-------------------------------------+ 396 | Binary Value | Octet Length | As Represented in Variable Size | 397 | | | Integer | 398 +--------------+--------------+-------------------------------------+ 399 | 10 | 1 | 1000 0010 | 400 | 10 | 2 | 0100 0000 0000 0010 | 401 | 10 | 3 | 0010 0000 0000 0000 0000 0010 | 402 | 10 | 4 | 0001 0000 0000 0000 0000 0000 0000 | 403 | | | 0010 | 404 +--------------+--------------+-------------------------------------+ 406 6. Element ID 408 The "Element ID" MUST be encoded as a "Variable Size Integer". By 409 default, "Element IDs" are encoded in lengths from one octet to four 410 octets, although "Element IDs" of greater lengths are used if the 411 octet length of the longest "Element ID" of the "EBML Document" is 412 declared in the "EBMLMaxIDLength Element" of the "EBML Header" (see 413 Section 11.2.4). The "VINT_DATA" component of the "Element ID" MUST 414 NOT be set to either all zero values or all one values. The 415 "VINT_DATA" component of the "Element ID" MUST be encoded at the 416 shortest valid length. For example, an "Element ID" with binary 417 encoding of "1011 1111" is valid, whereas an "Element ID" with binary 418 encoding of "0100 0000 0011 1111" stores a semantically equal 419 "VINT_DATA" but is invalid because a shorter "VINT" encoding is 420 possible. Additionally, an "Element ID" with binary encoding of 421 "1111 1111" is invalid since the "VINT_DATA" section is set to all 422 one values, whereas an "Element ID" with binary encoding of "0100 423 0000 0111 1111" stores a semantically equal "VINT_DATA" and is the 424 shortest "VINT" encoding is possible. 426 The following table details these specific examples further: 428 +------------+-------------+----------------+-----------------------+ 429 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status | 430 +------------+-------------+----------------+-----------------------+ 431 | | 1 | 0000000 | Invalid: "VINT_DATA" | 432 | | | | MUST NOT be set to | 433 | | | | all 0 | 434 | 0 | 1 | 00000000000000 | Invalid: "VINT_DATA" | 435 | | | | MUST NOT be set to | 436 | | | | all 0 | 437 | | 1 | 0000001 | Valid | 438 | 0 | 1 | 00000000000001 | Invalid: A shorter | 439 | | | | "VINT_DATA" encoding | 440 | | | | is available. | 441 | | 1 | 0111111 | Valid | 442 | 0 | 1 | 00000000111111 | Invalid: A shorter | 443 | | | | "VINT_DATA" encoding | 444 | | | | is available. | 445 | | 1 | 1111111 | Invalid: "VINT_DATA" | 446 | | | | MUST NOT be set to | 447 | | | | all 1 | 448 | 0 | 1 | 00000001111111 | Valid | 449 +------------+-------------+----------------+-----------------------+ 451 The octet length of an "Element ID" determines its "EBML Class". 453 +------------+--------------+--------------------------------+ 454 | EBML Class | Octet Length | Number of Possible Element IDs | 455 +------------+--------------+--------------------------------+ 456 | Class A | 1 | 2^7 - 2 = 126 | 457 | Class B | 2 | 2^14 - 2^7 - 1 = 16,255 | 458 | Class C | 3 | 2^21 - 2^14 - 1 = 2,080,767 | 459 | Class D | 4 | 2^28 - 2^21 - 1 = 266,338,303 | 460 +------------+--------------+--------------------------------+ 462 7. Element Data Size 464 The "Element Data Size" expresses the length in octets of "Element 465 Data". The "Element Data Size" itself MUST be encoded as a "Variable 466 Size Integer". By default, "Element Data Sizes" can be encoded in 467 lengths from one octet to eight octets, although "Element Data Sizes" 468 of greater lengths MAY be used if the octet length of the longest 469 "Element Data Size" of the "EBML Document" is declared in the 470 "EBMLMaxSizeLength Element" of the "EBML Header" (see 471 Section 11.2.5). Unlike the "VINT_DATA" of the "Element ID", the 472 "VINT_DATA" component of the "Element Data Size" is not mandated to 473 be encoded at the shortest valid length. For example, an "Element 474 Data Size" with binary encoding of "1011 1111" or a binary encoding 475 of "0100 0000 0011 1111" are both valid "Element Data Sizes" and both 476 store a semantically equal value (both "0b00000000111111" and 477 "0b0111111", the "VINT_DATA" sections of the examples, represent the 478 integer 63). 480 Although an "Element ID" with all "VINT_DATA" bits set to zero is 481 invalid, an "Element Data Size" with all "VINT_DATA" bits set to zero 482 is allowed for "EBML Element Types" which do not mandate a non-zero 483 length (see Section 8). An "Element Data Size" with all "VINT_DATA" 484 bits set to zero indicates that the "Element Data" is zero octets in 485 length. Such an "EBML Element" is referred to as an "Empty Element". 486 If an "Empty Element" has a "default" value declared then the "EBML 487 Reader" MUST interpret the value of the "Empty Element" as the 488 "default" value. If an "Empty Element" has no "default" value 489 declared then the "EBML Reader" MUST interpret the value of the 490 "Empty Element" as defined as part of the definition of the 491 corresponding "EBML Element Type" associated with the "Element ID". 493 An "Element Data Size" with all "VINT_DATA" bits set to one is 494 reserved as an indicator that the size of the "EBML Element" is 495 unknown. The only reserved value for the "VINT_DATA" of "Element 496 Data Size" is all bits set to one. An "EBML Element" with an unknown 497 "Element Data Size" is referred to as an "Unknown-Sized Element". 498 Only "Master Elements" SHALL be "Unknown-Sized Elements". "Master 499 Elements" MUST NOT use an unknown size unless the 500 "unknownsizeallowed" attribute of their "EBML Schema" is set to true 501 (see Section 11.1.4.10). The use of "Unknown-Sized Elements" allows 502 for an "EBML Element" to be written and read before the size of the 503 "EBML Element" is known. "Unknown-Sized Element" MUST NOT be used or 504 defined unnecessarily; however if the "Element Data Size" is not 505 known before the "Element Data" is written, such as in some cases of 506 data streaming, then "Unknown-Sized Elements" MAY be used. The end 507 of an "Unknown-Sized Element" is determined by whichever comes first: 508 the end of the file or the beginning of the next "EBML Element", 509 defined by this document or the corresponding "EBML Schema", that is 510 not independently valid as "Descendant Element" of the "Unknown-Sized 511 Element". 513 For "Element Data Sizes" encoded at octet lengths from one to eight, 514 this table depicts the range of possible values that can be encoded 515 as an "Element Data Size". An "Element Data Size" with an octet 516 length of 8 is able to express a size of 2^56-2 or 517 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum 518 possible value that can be stored as "Element Data Size" is referred 519 to as "VINTMAX". 521 +--------------+----------------------+ 522 | Octet Length | Possible Value Range | 523 +--------------+----------------------+ 524 | 1 | 0 to 2^7-2 | 525 | 2 | 0 to 2^14-2 | 526 | 3 | 0 to 2^21-2 | 527 | 4 | 0 to 2^28-2 | 528 | 5 | 0 to 2^35-2 | 529 | 6 | 0 to 2^42-2 | 530 | 7 | 0 to 2^49-2 | 531 | 8 | 0 to 2^56-2 | 532 +--------------+----------------------+ 534 If the length of "Element Data" equals "2^(n*7)-1" then the octet 535 length of the "Element Data Size" MUST be at least "n+1". This rule 536 prevents an "Element Data Size" from being expressed as a reserved 537 value. For example, an "EBML Element" with an octet length of 127 538 MUST NOT be encoded in an "Element Data Size" encoding with a one 539 octet length. The following table clarifies this rule by showing a 540 valid and invalid expression of an "Element Data Size" with a 541 "VINT_DATA" of 127 (which is equal to 2^(1*7)-1). 543 +------------+-------------+----------------+-----------------------+ 544 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element Data Size | 545 | | | | Status | 546 +------------+-------------+----------------+-----------------------+ 547 | | 1 | 1111111 | Reserved (meaning | 548 | | | | Unknown) | 549 | 0 | 1 | 00000001111111 | Valid (meaning 127 | 550 | | | | octets) | 551 +------------+-------------+----------------+-----------------------+ 553 8. EBML Element Types 555 "EBML Elements" are defined by an "EBML Schema" which MUST declare 556 one of the following "EBML Element Types" for each "EBML Element". 557 An "EBML Element Type" defines a concept of storing data within an 558 "EBML Element" that describes such characteristics as length, 559 endianness, and definition. 561 "EBML Elements" which are defined as a "Signed Integer Element", 562 "Unsigned Integer Element", "Float Element", or "Date Element" use 563 big endian storage. 565 8.1. Signed Integer Element 567 A "Signed Integer Element" MUST declare a length from zero to eight 568 octets. If the "EBML Element" is not defined to have a "default" 569 value, then a "Signed Integer Element" with a zero-octet length 570 represents an integer value of zero. 572 A "Signed Integer Element" stores an integer (meaning that it can be 573 written without a fractional component) which could be negative, 574 positive, or zero. Signed Integers MUST be stored with two's 575 complement notation with the leftmost bit being the sign bit. 576 Because "EBML" limits Signed Integers to 8 octets in length a "Signed 577 Integer Element" stores a number from -9,223,372,036,854,775,808 to 578 +9,223,372,036,854,775,807. 580 8.2. Unsigned Integer Element 582 An "Unsigned Integer Element" MUST declare a length from zero to 583 eight octets. If the "EBML Element" is not defined to have a 584 "default" value, then an "Unsigned Integer Element" with a zero-octet 585 length represents an integer value of zero. 587 An "Unsigned Integer Element" stores an integer (meaning that it can 588 be written without a fractional component) which could be positive or 589 zero. Because "EBML" limits Unsigned Integers to 8 octets in length 590 an "Unsigned Integer Element" stores a number from 0 to 591 18,446,744,073,709,551,615. 593 8.3. Float Element 595 A "Float Element" MUST declare a length of either zero octets (0 596 bit), four octets (32 bit) or eight octets (64 bit). If the "EBML 597 Element" is not defined to have a "default" value, then a "Float 598 Element" with a zero-octet length represents a numerical value of 599 zero. 601 A "Float Element" stores a floating-point number as defined in 602 [IEEE.754.1985]. 604 8.4. String Element 606 A "String Element" MUST declare a length in octets from zero to 607 "VINTMAX". If the "EBML Element" is not defined to have a "default" 608 value, then a "String Element" with a zero-octet length represents an 609 empty string. 611 A "String Element" MUST either be empty (zero-length) or contain 612 printable ASCII characters [RFC0020] in the range of "0x20" to 613 "0x7E". Octets with all bits set to zero MAY follow the string value 614 when needed, such as reducing the length of a stored string while 615 maintaining the same "Element Data Size". A string with one or more 616 octets with all bits set to zero and a string without one or more 617 octets with all bits set to zero are semantically equal. 619 8.5. UTF-8 Element 621 A "UTF-8 Element" MUST declare a length in octets from zero to 622 "VINTMAX". If the "EBML Element" is not defined to have a "default" 623 value, then a "UTF-8 Element" with a zero-octet length represents an 624 empty string. 626 A "UTF-8 Element" contains only a valid Unicode string as defined in 627 [RFC2279]. Octets with all bits set to zero MAY follow the string 628 value when needed, such as reducing the length of a stored UTF-8 data 629 while maintaining the same "Element Data Size". A UTF-8 value with 630 one or more octets with all bits set to zero and a UTF-8 value 631 without one or more octets with all bits set to zero are semantically 632 equal. 634 8.6. Date Element 636 A "Date Element" MUST declare a length of either zero octets or eight 637 octets. If the "EBML Element" is not defined to have a "default" 638 value, then a "Date Element" with a zero-octet length represents a 639 timestamp of 2001-01-01T00:00:00.000000000 UTC [RFC3339]. 641 The "Date Element" stores an integer in the same format as the 642 "Signed Integer Element" that expresses a point in time referenced in 643 nanoseconds from the precise beginning of the third millennium of the 644 Gregorian Calendar in Coordinated Universal Time (also known as 645 2001-01-01T00:00:00.000000000 UTC). This provides a possible 646 expression of time from 1708-09-11T00:12:44.854775808 UTC to 647 2293-04-11T11:47:16.854775807 UTC. 649 8.7. Master Element 651 A "Master Element" MUST declare a length in octets from zero to 652 "VINTMAX". The "Master Element" MAY also use an unknown length. See 653 Section 7 for rules that apply to elements of unknown length. 655 The "Master Element" contains zero, one, or many other elements. 656 "EBML Elements" contained within a "Master Element" MUST have the 657 "EBMLParentPath" of their "Element Path" equals to the 658 "EBMLReferencePath" of the "Master Element" "Element Path" (see 659 Section 11.1.4.2). "Element Data" stored within "Master Elements" 660 SHOULD only consist of "EBML Elements" and SHOULD NOT contain any 661 data that is not part of an "EBML Element". When "EBML" is used in 662 transmission or streaming, data that is not part of an "EBML Element" 663 is permitted to be present within a "Master Element" if 664 "unknownsizeallowed" is enabled within the definition for that 665 "Master Element". In this case, the "EBML Reader" should skip data 666 until a valid "Element ID" of the same "EBMLParentPath" or the next 667 upper level "Element Path" of the "Master Element" is found. What 668 "Element IDs" are considered valid within a "Master Element" is 669 identified by the "EBML Schema" for that version of the "EBML 670 Document Type". Any data contained within a "Master Element" that is 671 not part of a "Child Element" MUST be ignored. 673 8.8. Binary Element 675 A "Binary Element" MUST declare a length in octets from zero to 676 "VINTMAX". 678 The contents of a "Binary Element" should not be interpreted by the 679 "EBML Reader". 681 9. EBML Document 683 An "EBML Document" is comprised of only two components, an "EBML 684 Header" and an "EBML Body". An "EBML Document" MUST start with an 685 "EBML Header" that declares significant characteristics of the entire 686 "EBML Body". An "EBML Document" consists of "EBML Elements" and MUST 687 NOT contain any data that is not part of an "EBML Element". 689 9.1. EBML Header 691 The "EBML Header" is a declaration that provides processing 692 instructions and identification of the "EBML Body". The "EBML 693 Header" of an "EBML Document" is analogous to the XML Declaration of 694 an XML Document. 696 The "EBML Header" documents the "EBML Schema" (also known as the 697 "EBML DocType") that is used to semantically interpret the structure 698 and meaning of the "EBML Document". Additionally the "EBML Header" 699 documents the versions of both "EBML" and the "EBML Schema" that were 700 used to write the "EBML Document" and the versions required to read 701 the "EBML Document". 703 The "EBML Header" consists of a single "Master Element" with an 704 "Element Name" of "EBML" and "Element ID" of "0x1A45DFA3" (see 705 Section 11.2.1). The "EBML Header" MUST only contain "EBML Elements" 706 that are defined as part of this document. 708 All "EBML Elements" within the "EBML Header" MUST NOT use any 709 "Element ID" with a length greater than 4 octets. All "EBML 710 Elements" within the "EBML Header" MUST NOT use any "Element Data 711 Size" with a length greater than 4 octets. 713 9.2. EBML Body 715 All data of an "EBML Document" following the "EBML Header" is the 716 "EBML Body". The end of the "EBML Body", as well as the end of the 717 "EBML Document" that contains the "EBML Body", is considered as 718 whichever comes first: the beginning of a new "EBML Header" at the 719 "Root Level" or the end of the file. The "EBML Body" MUST consist 720 only of "EBML Elements" and MUST NOT contain any data that is not 721 part of an "EBML Element". This document defines precisely what 722 "EBML Elements" are to be used within the "EBML Header", but does not 723 name or define what "EBML Elements" are to be used within the "EBML 724 Body". The definition of what "EBML Elements" are to be used within 725 the "EBML Body" is defined by an "EBML Schema". 727 10. EBML Stream 729 An "EBML Stream" is a file that consists of one or many "EBML 730 Documents" that are concatenated together. An occurrence of a "EBML 731 Header" at the "Root Level" marks the beginning of an "EBML 732 Document". 734 11. Elements semantic 736 11.1. EBML Schema 738 An "EBML Schema" is an XML Document that defines the properties, 739 arrangement, and usage of "EBML Elements" that compose a specific 740 "EBML Document Type". The relationship of an "EBML Schema" to an 741 "EBML Document" may be considered analogous to the relationship of an 742 XML Schema [W3C.REC-xmlschema-0-20010502] to an XML Document 743 [W3C.REC-xml-20081126]. An "EBML Schema" MUST be clearly associated 744 with one or many "EBML Document Types". An "EBML Schema" must be 745 expressed as well-formed XML. An "EBML Document Type" is identified 746 by a string stored within the "EBML Header" in the "DocType Element"; 747 for example "matroska" or "webm" (see Section 11.2.6). The "DocType" 748 value for an "EBML Document Type" SHOULD be unique and persistent. 750 An "EBML Schema" MUST declare exactly one "EBML Element" at "Root 751 Level" (referred to as the "Root Element") that MUST occur exactly 752 once within an "EBML Document". The "Void Element" MAY also occur at 753 "Root Level" but is not considered to be "Root Elements" (see 754 Section 11.3.1). 756 The "EBML Schema" does not itself document the "EBML Header", but 757 documents all data of the "EBML Document" that follows the "EBML 758 Header". The "EBML Header" itself is documented by this 759 specification in the "EBML Header Elements" (see Section 11.2). The 760 "EBML Schema" also does not document "Global Elements" that are 761 defined by this document (namely the "Void Element" and the "CRC-32 762 Element"). 764 11.1.1. Element 766 As an XML Document, the "EBML Schema" MUST use "" as the 767 top level element. The "" element MAY contain 768 "" sub-elements. 770 11.1.2. Attributes 772 Within an "EBML Schema" the "" element uses the following 773 attributes: 775 11.1.2.1. docType 777 The "docType" lists the official name of the "EBML Document Type" 778 that is defined by the "EBML Schema"; for example, "". 781 The "docType" attribute is REQUIRED within the "" 782 Element. 784 11.1.2.2. version 786 The "version" lists an incremental non-negative integer that 787 specifies the version of the docType documented by the "EBML Schema". 788 Unlike XML Schemas, an "EBML Schema" documents all versions of a 789 docType's definition rather than using separate "EBML Schemas" for 790 each version of a "docType". "EBML Elements" may be introduced and 791 deprecated by using the "minver" and "maxver" attributes of 792 "". 794 The "version" attribute is REQUIRED within the "" 795 Element. 797 11.1.3. Element 799 Each "" defines one "EBML Element" through the use of 800 several attributes that are defined in Section 11.1.2. "EBML 801 Schemas" MAY contain additional attributes to extend the semantics 802 but MUST NOT conflict with the definitions of the "" 803 attributes defined within this document. 805 The "" nodes contain a description of the meaning and use of 806 the "EBML Element" stored within one or many "" sub- 807 elements and zero or one "" sub-element. All 808 "" nodes MUST be sub-elements of the "". 810 11.1.4. Attributes 812 Within an "EBML Schema" the "" uses the following attributes 813 to define an "EBML Element": 815 11.1.4.1. name 817 The "name" provides the official human-readable name of the "EBML 818 Element". The value of the name MUST be in the form of characters 819 "A" to "Z", "a" to "z", "0" to "9", "-" and ".". 821 The "name" attribute is REQUIRED. 823 11.1.4.2. path 825 The path defines the allowed storage locations of the "EBML Element" 826 within an "EBML Document". This path MUST be defined with the full 827 hierarchy of "EBML Elements" separated with a "/". The top "EBML 828 Element" in the path hierarchy being the first in the value. The 829 syntax of the "path" attribute is defined using this Augmented 830 Backus-Naur Form (ABNF) [RFC5234] with the case sensitive update 831 [RFC7405] notation: 833 The "path" attribute is REQUIRED. 835 EBMLFullPath = EBMLElementOccurrence "(" EBMLReferencePath ")" 836 EBMLReferencePath = [EBMLParentPath] EBMLElementPath 837 EBMLParentPath = EBMLFixedParent EBMLLastParent 838 EBMLFixedParent = *(EBMLPathAtom) 839 EBMLElementPath = EBMLPathAtom / EBMLPathAtomRecursive 840 EBMLPathAtom = PathDelimiter EBMLAtomName 841 EBMLPathAtomRecursive = "(1*(" EBMLPathAtom "))" 842 EBMLLastParent = EBMLPathAtom / EBMLVariableParent 843 EBMLVariableParent = "(" VariableParentOccurrence "\)" 844 EBMLAtomName = 1*(EBMLNameChar) 845 EBMLNameChar = ALPHA / DIGIT / "-" / "." 846 PathDelimiter = "\" 847 EBMLElementOccurrence = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence] 848 EBMLMinOccurrence = 1*DIGIT 849 EBMLMaxOccurrence = 1*DIGIT 850 VariableParentOccurrence = [PathMinOccurrence] "*" [PathMaxOccurrence] 851 PathMinOccurrence = 1*DIGIT 852 PathMaxOccurrence = 1*DIGIT 853 The ""*"", ""("" and "")"" symbols MUST be interpreted as they are 854 defined in the ABNF. 856 The "EBMLPathAtom" part of the "EBMLElementPath" MUST be equal to the 857 "name" attribute of the "EBML Schema". 859 The starting "PathDelimiter" of the path corresponds to the root of 860 the "EBML Document". 862 The "EBMLElementOccurrence" part is interpreted as an ABNF Variable 863 Repetition. The repetition amounts correspond to how many times the 864 "EBML Element" can be found in its "Parent Element". 866 The "EBMLMinOccurrence" represents the minimum number of occurrences 867 of this "EBML Element" within its "Parent Element". Each instance of 868 the "Parent Element" MUST contain at least this many instances of 869 this "EBML Element". If the "EBML Element" has an empty 870 "EBMLParentPath" then "EBMLMinOccurrence" refers to constraints on 871 the occurrence of the "EBML Element" within the "EBML Document". If 872 "EBMLMinOccurrence" is not present then that "EBML Element" is 873 considered to have a "EBMLMinOccurrence" value of 0. The semantic 874 meaning of "EBMLMinOccurrence" within an "EBML Schema" is considered 875 analogous to the meaning of "minOccurs" within an "XML Schema". 876 "EBML Elements" with "EBMLMinOccurrence" set to "1" that also have a 877 "default" value (see Section 11.1.4.8) declared are not REQUIRED to 878 be stored but are REQUIRED to be interpreted, see Section 11.1.15. 879 An "EBML Element" defined with a "EBMLMinOccurrence" value greater 880 than zero is called a "Mandatory EBML Element". 882 The "EBMLMaxOccurrence" represents the maximum number of occurrences 883 of this "EBML Element" within its "Parent Element". Each instance of 884 the "Parent Element" MUST contain at most this many instances of this 885 "EBML Element". If the "EBML Element" has an empty "EBMLParentPath" 886 then "EBMLMaxOccurrence" refers to constraints on the occurrence of 887 the "EBML Element" within the "EBML Document". If 888 "EBMLMaxOccurrence" is not present then that "EBML Element" is 889 considered to have no maximum occurrence. The semantic meaning of 890 "EBMLMaxOccurrence" within an "EBML Schema path" is considered 891 analogous to the meaning of "maxOccurs" within an "XML Schema". 893 The "VariableParentOccurrence" part is interpreted as an ABNF 894 Variable Repetition. The repetition amounts correspond to the amount 895 of unspecified "Parent Element" levels there can be between the 896 "EBMLFixedParent" and the actual "EBMLElementPath". 898 If the path contains a "EBMLPathAtomRecursive" part, the "EBML 899 Element" can occur within itself recursively (see the 900 Section 11.1.4.11). 902 11.1.4.3. id 904 The "Element ID" encoded as a "Variable Size Integer" expressed in 905 hexadecimal notation prefixed by a "0x" that is read and stored in 906 big-endian order. To reduce the risk of false positives while 907 parsing "EBML Streams", the "Element IDs" of the "Root Element" and 908 "Top-Level Elements" SHOULD be at least 4 octets in length. "Element 909 IDs" defined for use at "Root Level" or directly under the "Root 910 Level" MAY use shorter octet lengths to facilitate padding and 911 optimize edits to "EBML Documents"; for instance, the "Void Element" 912 uses an "Element ID" with a one octet length to allow its usage in 913 more writing and editing scenarios. 915 The "id" attribute is REQUIRED. 917 11.1.4.4. minOccurs 919 An integer expressing the minimum number of occurrences of this "EBML 920 Element" within its "Parent Element". The "minOccurs" value MUST be 921 equal to the "EBMLMinOccurrence" value of the "path". 923 The "minOccurs" attribute is OPTIONAL. If the "minOccurs" attribute 924 is not present then that "EBML Element" is considered to have a 925 "minOccurs" value of 0. 927 11.1.4.5. maxOccurs 929 An integer expressing the maximum number of occurrences of this "EBML 930 Element" within its "Parent Element". The "maxOccurs" value MUST be 931 equal to the "EBMLMaxOccurrence" value of the "path". 933 The "maxOccurs" attribute is OPTIONAL. If the "maxOccurs" attribute 934 is not present then that "EBML Element" is considered to have no 935 maximum occurrence, similar to "unbounded" in the XML world. 937 11.1.4.6. range 939 A numerical range for "EBML Elements" which are of numerical types 940 (Unsigned Integer, Signed Integer, Float, and Date). If specified 941 the value of the "EBML Element" MUST be within the defined range. 942 See Section 11.1.13 for rules applied to expression of range values. 944 The "range" attribute is OPTIONAL. If the "range" attribute is not 945 present then any value legal for the "type" attribute is valid. 947 11.1.4.7. size 949 A value to express the valid length of the "Element Data" as written 950 measured in octets. The "size" provides a constraint in addition to 951 the Length value of the definition of the corresponding "EBML Element 952 Type". This "size" MUST be expressed as either a non-negative 953 integer or a range (see Section 11.1.13) that consists of only non- 954 negative integers and valid operators. 956 The "size" attribute is OPTIONAL. If the "size" attribute is not 957 present for that "EBML Element" then that "EBML Element" is only 958 limited in size by the definition of the associated "EBML Element 959 Type". 961 11.1.4.8. default 963 If an Element is mandatory (has a "EBMLMinOccurrence" value greater 964 than zero) but not written within its "Parent Element" or stored as 965 an "Empty Element", then the "EBML Reader" of the "EBML Document" 966 MUST semantically interpret the "EBML Element" as present with this 967 specified default value for the "EBML Element". "EBML Elements" that 968 are "Master Elements" MUST NOT declare a "default" value. "EBML 969 Elements" with a "minOccurs" value greater than 1 MUST NOT declare a 970 "default" value. 972 The "default" attribute is OPTIONAL. 974 11.1.4.9. type 976 The "type" MUST be set to one of the following values: 'integer' 977 (signed integer), 'uinteger' (unsigned integer), 'float', 'string', 978 'date', 'utf-8', 'master', or 'binary'. The content of each "type" 979 is defined within Section 8. 981 The "type" attribute is REQUIRED. 983 11.1.4.10. unknownsizeallowed 985 A boolean to express if an "EBML Element" MAY be used as an "Unknown- 986 Sized Element" (having all "VINT_DATA" bits of "Element Data Size" 987 set to 1). "EBML Elements" that are not "Master Elements" MUST NOT 988 set "unknownsizeallowed" to true. An "EBML Element" that is defined 989 with an "unknownsizeallowed" attribute set to 1 MUST also have the 990 "unknownsizeallowed" attribute of its "Parent Element" set to 1. 992 The "unknownsizeallowed" attribute is OPTIONAL. If the 993 "unknownsizeallowed" attribute is not used then that "EBML Element" 994 is not allowed to use an unknown "Element Data Size". 996 11.1.4.11. recursive 998 A boolean to express if an "EBML Element" MAY be stored recursively. 999 In this case the "EBML Element" MAY be stored within another "EBML 1000 Element" that has the same "Element ID". Which itself can be stored 1001 in an "EBML Element" that has the same "Element ID", and so on. 1002 "EBML Elements" that are not "Master Elements" MUST NOT set 1003 "recursive" to true. 1005 If the "path" contains a "EBMLPathAtomRecursive" part then the 1006 "recursive" value MUST be true and false otherwise. 1008 The "recursive" attribute is OPTIONAL. If the "recursive" attribute 1009 is not present then the "EBML Element" MUST NOT be used recursively. 1011 11.1.4.12. minver 1013 The "minver" (minimum version) attribute stores a non-negative 1014 integer that represents the first version of the "docType" to support 1015 the "EBML Element". 1017 The "minver" attribute is OPTIONAL. If the "minver" attribute is not 1018 present then the "EBML Element" has a minimum version of "1". 1020 11.1.4.13. maxver 1022 The "maxver" (maximum version) attribute stores a non-negative 1023 integer that represents the last or most recent version of the 1024 "docType" to support the element. "maxver" MUST be greater than or 1025 equal to "minver". 1027 The "maxver" attribute is OPTIONAL. If the "maxver" attribute is not 1028 present then the "EBML Element" has a maximum version equal to the 1029 value stored in the "version" attribute of "". 1031 11.1.5. Element 1033 The "" element provides additional information about 1034 the "EBML Element". 1036 11.1.6. Attributes 1038 11.1.6.1. lang 1040 A "lang" attribute which is set to the [RFC5646] value of the 1041 language of the element's documentation. 1043 The "lang" attribute is OPTIONAL. 1045 11.1.6.2. type 1047 A "type" attribute distinguishes the meaning of the documentation. 1048 Values for the "" sub-element's "type" attribute MUST 1049 include one of the following: "definition", "rationale", "usage 1050 notes", and "references". 1052 The "type" attribute is OPTIONAL. 1054 11.1.7. Element 1056 The "" element provides information about restrictions 1057 to the allowable values for the "EBML Element" which are listed in 1058 "" elements. 1060 11.1.8. Element 1062 The "" element stores a list of values allowed for storage in 1063 the "EBML Element". The values MUST match the "type" of the "EBML 1064 Element" (for example "" can not be a valid value 1065 for a "EBML Element" that is defined as an unsigned integer). An 1066 "" element MAY also store "" elements to further 1067 describe the "". 1069 11.1.9. Attributes 1071 11.1.9.1. label 1073 The "label" provides a concise expression for human consumption that 1074 describes what the "value" of the "" represents. 1076 The "label" attribute is OPTIONAL. 1078 11.1.9.2. value 1080 The "value" represents data that MAY be stored within the "EBML 1081 Element". 1083 The "value" attribute is REQUIRED. 1085 11.1.10. XML Schema for EBML Schema 1087 1088 1089 1090 1091 1092 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 11.1.11. EBML Schema Example 1139 1140 1141 1142 1143 Container of data and 1144 attributes representing one or many files. 1145 1146 1147 An attached file. 1148 1149 1151 Filename of the attached file. 1152 1153 1154 1156 MIME type of the file. 1157 1158 1160 Modification timestamp of the file. 1161 1162 1163 1165 The data of the file. 1166 1167 1169 11.1.12. Identically Recurring Elements 1171 An "Identically Recurring Element" is an "EBML Element" that MAY 1172 occur within its "Parent Element" more than once but that each 1173 recurrence within that "Parent Element" MUST be identical both in 1174 storage and semantics. "Identically Recurring Elements" are 1175 permitted to be stored multiple times within the same "Parent 1176 Element" in order to increase data resilience and optimize the use of 1177 "EBML" in transmission. For instance a pertinent "Top-Level Element" 1178 could be periodically resent within a data stream so that an "EBML 1179 Reader" which starts reading the stream from the middle could better 1180 interpret the contents. "Identically Recurring Elements" SHOULD 1181 include a "CRC-32 Element" as a "Child Element"; this is especially 1182 recommended when "EBML" is used for long-term storage or 1183 transmission. If a "Parent Element" contains more than one copy of 1184 an "Identically Recurring Element" which includes a "CRC-32 Element" 1185 as a "Child Element" then the first instance of the "Identically 1186 Recurring Element" with a valid CRC-32 value should be used for 1187 interpretation. If a "Parent Element" contains more than one copy of 1188 an "Identically Recurring Element" which does not contain a "CRC-32 1189 Element" or if "CRC-32 Elements" are present but none are valid then 1190 the first instance of the "Identically Recurring Element" should be 1191 used for interpretation. 1193 11.1.13. Expression of range 1195 The "range" attribute MUST only be used with "EBML Elements" that are 1196 either "signed integer", "unsigned integer", "float", or "date". The 1197 "range" expression may contain whitespace for readability but 1198 whitespace within a "range" expression MUST NOT convey meaning. The 1199 expression of the "range" MUST adhere to one of the following forms: 1201 o "x-y" where x and y are integers or floats and "y" MUST be greater 1202 than "x", meaning that the value MUST be greater than or equal to 1203 "x" and less than or equal to "y". "x" MUST be less than "y". 1205 o ">x" where "x" is an integer or float, meaning that the value MUST 1206 be greater than "x". 1208 o ">=x" where "x" is an integer or float, meaning that the value 1209 MUST be greater than or equal to "x". 1211 o "=4 1368 default: 4 1370 type: Unsigned Integer 1371 description: The "EBMLMaxIDLength Element" stores the maximum length 1372 in octets of the "Element IDs" to be found within the "EBML Body". 1373 An "EBMLMaxIDLength Element" value of four is RECOMMENDED, though 1374 larger values are allowed. 1376 11.2.5. EBMLMaxSizeLength Element 1378 name: "EBMLMaxSizeLength" 1380 path: "1*1(\EBML\EBMLMaxSizeLength)" 1382 id "0x42F3" 1384 minOccurs: 1 1386 maxOccurs: 1 1388 range: not 0 1390 default: 8 1392 type: Unsigned Integer 1394 description: The "EBMLMaxSizeLength Element" stores the maximum 1395 length in octets of the expression of all "Element Data Sizes" to be 1396 found within the "EBML Body". To be clear the "EBMLMaxSizeLength 1397 Element" documents the maximum 'length' of all "Element Data Size" 1398 expressions within the "EBML Body" and not the maximum 'value' of all 1399 "Element Data Size" expressions within the "EBML Body". "EBML 1400 Elements" that have an "Element Data Size" expression which is larger 1401 in octets than what is expressed by "EBMLMaxSizeLength ELEMENT" SHALL 1402 be considered invalid. 1404 11.2.6. DocType Element 1406 name: "DocType" 1408 path: "1*1(\EBML\DocType)" 1410 id "0x4282" 1412 minOccurs: 1 1414 maxOccurs: 1 1416 size: >0 1418 type: String 1419 description: A string that describes and identifies the content of 1420 the "EBML Body" that follows this "EBML Header". 1422 11.2.7. DocTypeVersion Element 1424 name: "DocTypeVersion" 1426 path: "1*1(\EBML\DocTypeVersion)" 1428 id "0x4287" 1430 minOccurs: 1 1432 maxOccurs: 1 1434 default: 1 1436 type: Unsigned Integer 1438 description: The version of "DocType" interpreter used to create the 1439 "EBML Document". 1441 11.2.8. DocTypeReadVersion Element 1443 name: DocTypeReadVersion 1445 path: "1*1(\EBML\DocTypeReadVersion)" 1447 id "0x4285" 1449 minOccurs: 1 1451 maxOccurs: 1 1453 default: 1 1455 type: Unsigned Integer 1457 description: The minimum "DocType" version an "EBML Reader" has to 1458 support to read this "EBML Document". The value of the 1459 "DocTypeReadVersion Element" MUST be less than or equal to the value 1460 of the "DocTypeVersion Element". 1462 11.3. Global elements (used everywhere in the format) 1464 name: CRC-32 1466 path: "*1((1*\)\CRC-32)" 1467 id: "0xBF" 1469 minOccurs: 0 1471 maxOccurs: 1 1473 size: 4 1475 type: Binary 1477 description: The "CRC-32 Element" contains a 32-bit Cyclic Redundancy 1478 Check value of all the "Element Data" of the "Parent Element" as 1479 stored except for the "CRC-32 Element" itself. When the "CRC-32 1480 Element" is present, the "CRC-32 Element" MUST be the first ordered 1481 "EBML Element" within its "Parent Element" for easier reading. All 1482 "Top-Level Elements" of an "EBML Document" that are "Master Elements" 1483 SHOULD include a "CRC-32 Element" as a "Child Element". The CRC in 1484 use is the IEEE-CRC-32 algorithm as used in the [ISO.3309.1979] 1485 standard and in section 8.1.1.6.2 of [ITU.V42.1994], with initial 1486 value of "0xFFFFFFFF". The CRC value MUST be computed on a little 1487 endian bitstream and MUST use little endian storage. 1489 11.3.1. Void Element 1491 name: Void 1493 path: "*((*\)\Void)" 1495 id: "0xEC" 1497 minOccurs: 0 1499 type: Binary 1501 description: Used to void damaged data, to avoid unexpected behaviors 1502 when using damaged data. The content is discarded. Also used to 1503 reserve space in a sub-element for later use. 1505 12. References 1507 12.1. Normative References 1509 [IEEE.754.1985] 1510 Institute of Electrical and Electronics Engineers, 1511 "Standard for Binary Floating-Point Arithmetic", 1512 IEEE Standard 754, August 1985. 1514 [ISO.3309.1979] 1515 International Organization for Standardization, "Data 1516 communication - High-level data link control procedures - 1517 Frame structure", ISO Standard 3309, 1979. 1519 [ISO.9899.2011] 1520 International Organization for Standardization, 1521 "Programming languages - C", ISO Standard 9899, 2011. 1523 [ITU.V42.1994] 1524 International Telecommunications Union, "Error-correcting 1525 Procedures for DCEs Using Asynchronous-to-Synchronous 1526 Conversion", ITU-T Recommendation V.42, 1994. 1528 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1529 RFC 20, DOI 10.17487/RFC0020, October 1969, 1530 . 1532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1533 Requirement Levels", BCP 14, RFC 2119, 1534 DOI 10.17487/RFC2119, March 1997, 1535 . 1537 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 1538 10646", RFC 2279, DOI 10.17487/RFC2279, January 1998, 1539 . 1541 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1542 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1543 . 1545 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1546 Specifications: ABNF", STD 68, RFC 5234, 1547 DOI 10.17487/RFC5234, January 2008, 1548 . 1550 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1551 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1552 September 2009, . 1554 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1555 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1556 . 1558 [W3C.REC-xml-20081126] 1559 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1560 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1561 Edition)", World Wide Web Consortium Recommendation REC- 1562 xml-20081126, November 2008, 1563 . 1565 12.2. Informative References 1567 [W3C.REC-xmlschema-0-20010502] 1568 Fallside, D., "XML Schema Part 0: Primer", World Wide Web 1569 Consortium Recommendation REC-xmlschema-0-20010502, May 1570 2001, 1571 . 1573 Authors' Addresses 1575 Steve Lhomme 1577 Dave Rice 1579 Moritz Bunkus