idnits 2.17.1 draft-ietf-cellar-ebml-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 27, 2018) is 1971 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 981, but not defined == Missing Reference: 'EBMLMinOccurrence' is mentioned on line 992, but not defined == Missing Reference: 'EBMLMaxOccurrence' is mentioned on line 992, but not defined == Missing Reference: 'PathMinOccurrence' is mentioned on line 995, but not defined == Missing Reference: 'PathMaxOccurrence' is mentioned on line 995, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.V42.1994' Summary: 0 errors (**), 0 flaws (~~), 7 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: May 31, 2019 6 M. Bunkus 7 November 27, 2018 9 Extensible Binary Meta Language 10 draft-ietf-cellar-ebml-08 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 https://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 May 31, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . 4 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 4. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Variable Size Integer . . . . . . . . . . . . . . . . . . . . 7 62 5.1. VINT_WIDTH . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. VINT_MARKER . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3. VINT_DATA . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.4. VINT Examples . . . . . . . . . . . . . . . . . . . . . . 9 66 6. Element ID . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. Element Data Size . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 14 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. Terminating Elements . . . . . . . . . . . . . . . . . . . . 15 78 10. Guidelines for Updating Elements . . . . . . . . . . . . . . 16 79 10.1. Reducing a Element Data in Size . . . . . . . . . . . . 16 80 10.1.1. Adding a Void Element . . . . . . . . . . . . . . . 16 81 10.1.2. Extending the Element Data Size . . . . . . . . . . 16 82 10.1.3. Terminating Element Data . . . . . . . . . . . . . . 17 83 10.2. Considerations when Updating Elements with CRC . . . . . 17 84 11. EBML Document . . . . . . . . . . . . . . . . . . . . . . . . 18 85 11.1. EBML Header . . . . . . . . . . . . . . . . . . . . . . 18 86 11.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . . 18 87 12. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 13. Elements semantic . . . . . . . . . . . . . . . . . . . . . . 19 89 13.1. EBML Schema . . . . . . . . . . . . . . . . . . . . . . 19 90 13.1.1. Element . . . . . . . . . . . . . . . . 20 91 13.1.2. Attributes . . . . . . . . . . . . . . 20 92 13.1.3. Element . . . . . . . . . . . . . . . . . 20 93 13.1.4. Attributes . . . . . . . . . . . . . . . . 21 94 13.1.5. Element . . . . . . . . . . . . . . 26 95 13.1.6. Attributes . . . . . . . . . . . . . 26 96 13.1.7. Element . . . . . . . . . . . . . . . 26 97 13.1.8. Element . . . . . . . . . . . . . . . . . . . 26 98 13.1.9. Attributes . . . . . . . . . . . . . . . . . 26 99 13.1.10. XML Schema for EBML Schema . . . . . . . . . . . . . 27 100 13.1.11. EBML Schema Example . . . . . . . . . . . . . . . . 28 101 13.1.12. Identically Recurring Elements . . . . . . . . . . . 29 102 13.1.13. Expression of range . . . . . . . . . . . . . . . . 30 103 13.1.14. Textual expression of floats . . . . . . . . . . . . 30 104 13.1.15. Note on the use of default attributes to define 105 Mandatory EBML Elements . . . . . . . . . . . . . . 31 106 13.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 32 107 13.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 32 108 13.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 32 109 13.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 33 110 13.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 33 111 13.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 34 112 13.2.6. DocType Element . . . . . . . . . . . . . . . . . . 34 113 13.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 35 114 13.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 35 115 13.2.9. DocTypeExtension Element . . . . . . . . . . . . . . 36 116 13.2.10. DocTypeExtensionName Element . . . . . . . . . . . . 36 117 13.2.11. DocTypeExtensionVersion Element . . . . . . . . . . 36 118 13.3. Global Elements . . . . . . . . . . . . . . . . . . . . 37 119 13.3.1. CRC-32 Element . . . . . . . . . . . . . . . . . . . 37 120 13.3.2. Void Element . . . . . . . . . . . . . . . . . . . . 38 121 14. Considerations for Reading EBML Data . . . . . . . . . . . . 38 122 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 123 15.1. CELLAR EBML Element ID Registry . . . . . . . . . . . . 38 124 15.2. CELLAR EBML DocType Registry . . . . . . . . . . . . . . 40 125 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 16.1. Normative References . . . . . . . . . . . . . . . . . . 41 127 16.2. Informative References . . . . . . . . . . . . . . . . . 42 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 130 1. Introduction 132 "EBML", short for Extensible Binary Meta Language, specifies a binary 133 and octet (byte) aligned format inspired by the principle of XML (a 134 framework for structuring data). 136 The goal of this document is to define a generic, binary, space- 137 efficient format that can be used to define more complex formats 138 (such as containers for multimedia content) using an "EBML Schema". 139 The definition of the "EBML" format recognizes the idea behind HTML 140 and XML as a good one: separate structure and semantics allowing the 141 same structural layer to be used with multiple, possibly widely 142 differing semantic layers. Except for the "EBML Header" and a few 143 "Global Elements" this specification does not define particular 144 "EBML" format semantics; however this specification is intended to 145 define how other "EBML"-based formats can be defined. 147 "EBML" uses a simple approach of building "Elements" upon three 148 pieces of data (tag, length, and value) as this approach is well 149 known, easy to parse, and allows selective data parsing. The "EBML" 150 structure additionally allows for hierarchical arrangement to support 151 complex structural formats in an efficient manner. 153 2. Notation and Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 This document defines specific terms in order to define the format 160 and application of "EBML". Specific terms are defined below: 162 "EBML": Extensible Binary Meta Language 164 "EBML Document Type": A name provided by an "EBML Schema" to 165 designate a particular implementation of "EBML" for a data format 166 (e.g.: matroska and webm). 168 "EBML Schema": A standardized definition for the structure of an 169 "EBML Document Type". 171 "EBML Document": A datastream comprised of only two components, an 172 "EBML Header" and an "EBML Body". 174 "EBML Reader": A data parser that interprets the semantics of an 175 "EBML Document" and creates a way for programs to use "EBML". 177 "EBML Stream": A file that consists of one or more "EBML Documents" 178 that are concatenated together. 180 "EBML Header": A declaration that provides processing instructions 181 and identification of the "EBML Body". The "EBML Header" may be 182 considered as analogous to an XML Declaration [W3C.REC-xml-20081126] 183 (see section 2.8 on Prolog and Document Type Declaration). 185 "EBML Body": All data of an "EBML Document" following the "EBML 186 Header". 188 "Variable Size Integer": A compact variable-length binary value which 189 defines its own length. 191 "VINT": Also known as "Variable Size Integer". 193 "EBML Element": A foundation block of data that contains three parts: 194 an "Element ID", an "Element Data Size", and "Element Data". 196 "Element ID": The "Element ID" is a binary value, encoded as a 197 "Variable Size Integer", used to uniquely identify a defined "EBML 198 Element" within a specific "EBML Schema". 200 "EBML Class": A representation of the octet length of an "Element 201 ID". 203 "Element Data Size": An expression, encoded as a "Variable Size 204 Integer", of the length in octets of "Element Data". 206 "VINTMAX": The maximum possible value that can be stored as "Element 207 Data Size". 209 "Unknown-Sized Element": An "Element" with an unknown "Element Data 210 Size". 212 "Element Data": The value(s) of the "EBML Element" which is 213 identified by its "Element ID" and "Element Data Size". The form of 214 the "Element Data" is defined by this document and the corresponding 215 "EBML Schema" of the Element's "EBML Document Type". 217 "Root Level": The starting level in the hierarchy of an "EBML 218 Document". 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 "Top-Level Element": An "EBML Element" defined to only occur as a 226 "Child Element" of the "Root Element". 228 "Master Element": The "Master Element" contains zero, one, or many 229 other "EBML Elements". 231 "Child Element": A "Child Element" is a relative term to describe the 232 "EBML Elements" immediately contained within a "Master Element". 234 "Parent Element": A relative term to describe the "Master Element" 235 which contains a specified element. For any specified "EBML Element" 236 that is not at "Root Level", the "Parent Element" refers to the 237 "Master Element" in which that "EBML Element" is contained. 239 "Descendant Element": A relative term to describe any "EBML Elements" 240 contained within a "Master Element", including any of the "Child 241 Elements" of its "Child Elements", and so on. 243 "Void Element": A "Void Element" is an "Element" used to overwrite 244 damaged data or reserve space within a "Master Element" for later 245 use. 247 "Element Name": The official human-readable name of the "EBML 248 Element". 250 "Element Path": The hierarchy of "Parent Element" where the "EBML 251 Element" is expected to be found in the "EBML Body". 253 "Empty Element": An "EBML Element" that has an "Element Data Size" 254 with all "VINT_DATA" bits set to zero, which indicates that the 255 "Element Data" of the "Element" is zero octets in length. 257 3. Security Considerations 259 "EBML" itself does not offer any kind of security and does not 260 provide confidentiality. "EBML" does not provide any kind of 261 authorization. "EBML" only offers marginally useful and effective 262 data integrity options, such as CRC elements. 264 Even if the semantic layer offers any kind of encryption, "EBML" 265 itself could leak information at both the semantic layer (as declared 266 via the "DocType Element") and within the "EBML" structure (the 267 presence of "EBML Elements" can be derived even with an unknown 268 semantic layer using a heuristic approach; not without errors, of 269 course, but with a certain degree of confidence). 271 Attacks on an "EBML Reader" could include: 273 o Invalid "Element IDs" that are longer than the limit stated in the 274 "EBMLMaxIDLength Element" of the "EBML Header". 276 o Invalid "Element IDs" that are not encoded in the shortest- 277 possible way. 279 o Invalid "Element IDs" comprised of reserved values. 281 o Invalid "Element Data Size" values that are longer than the limit 282 stated in the "EBMLMaxSizeLength Element" of the "EBML Header". 284 o Invalid "Element Data Size" values (e.g. extending the length of 285 the "EBML Element" beyond the scope of the "Parent Element"; 286 possibly triggering access-out-of-bounds issues). 288 o Very high lengths in order to force out-of-memory situations 289 resulting in a denial of service, access-out-of-bounds issues etc. 291 o Missing "EBML Elements" that are mandatory and have no declared 292 default value. 294 o Usage of "0x00" octets in "EBML Elements" with a string type. 296 o Usage of invalid UTF-8 encoding in "EBML Elements" of UTF-8 type 297 (e.g. in order to trigger access-out-of-bounds or buffer overflow 298 issues). 300 o Usage of invalid data in "EBML Elements" with a date type. 302 Side channel attacks could exploit: 304 o The semantic equivalence of the same string stored in a "String 305 Element" or "UTF-8 Element" with and without zero-bit padding. 307 o The semantic equivalence of "VINT_DATA" within "Element Data Size" 308 with to different lengths due to left-padding zero bits. 310 o Data contained within a "Master Element" which is not itself part 311 of an "EBML Element". 313 o Extraneous copies of "Identically Recurring Element". 315 o Copies of "Identically Recurring Element" within a "Parent 316 Element" that contain invalid "CRC-32 Elements". 318 o Use of "Void Elements". 320 4. Structure 322 "EBML" uses a system of "Elements" to compose an "EBML Document". 323 "EBML Elements" incorporate three parts: an "Element ID", an "Element 324 Data Size", and "Element Data". The "Element Data", which is 325 described by the "Element ID", includes either binary data, one or 326 many other "EBML Elements", or both. 328 5. Variable Size Integer 330 The "Element ID" and "Element Data Size" are both encoded as a 331 "Variable Size Integer", developed according to a UTF-8 like system. 332 The "Variable Size Integer" is composed of a "VINT_WIDTH", 333 "VINT_MARKER", and "VINT_DATA", in that order. "Variable Size 334 Integers" MUST left-pad the "VINT_DATA" value with zero bits so that 335 the whole "Variable Size Integer" is octet-aligned. "Variable Size 336 Integer" will be referred to as "VINT" for shorthand. 338 5.1. VINT_WIDTH 340 Each "Variable Size Integer" begins with a "VINT_WIDTH" which 341 consists of zero or many zero-value bits. The count of consecutive 342 zero-values of the "VINT_WIDTH" plus one equals the length in octets 343 of the "Variable Size Integer". For example, a "Variable Size 344 Integer" that starts with a "VINT_WIDTH" which contains zero 345 consecutive zero-value bits is one octet in length and a "Variable 346 Size Integer" that starts with one consecutive zero-value bit is two 347 octets in length. The "VINT_WIDTH" MUST only contain zero-value bits 348 or be empty. 350 Within the "EBML Header" the "VINT_WIDTH" MUST NOT exceed three bits 351 in length (meaning that the "Variable Size Integer" MUST NOT exceed 352 four octets in length). Within the "EBML Body", when a "VINT" is 353 used to express an "Element ID", the maximum length allowed for the 354 "VINT_WIDTH" is one less than the value set in the "EBMLMaxIDLength 355 Element". Within the "EBML Body", when a "VINT" is used to express 356 an "Element Data Size", the maximum length allowed for the 357 "VINT_WIDTH" is one less than the value set in the "EBMLMaxSizeLength 358 Element". 360 5.2. VINT_MARKER 362 The "VINT_MARKER" serves as a separator between the "VINT_WIDTH" and 363 "VINT_DATA". Each "Variable Size Integer" MUST contain exactly one 364 "VINT_MARKER". The "VINT_MARKER" MUST be one bit in length and 365 contain a bit with a value of one. The first bit with a value of one 366 within the "Variable Size Integer" is the "VINT_MARKER". 368 5.3. VINT_DATA 370 The "VINT_DATA" portion of the "Variable Size Integer" includes all 371 data that follows (but not including) the "VINT_MARKER" until end of 372 the "Variable Size Integer" whose length is derived from the 373 "VINT_WIDTH". The bits required for the "VINT_WIDTH" and the 374 "VINT_MARKER" combined use one out of eight bits of the total length 375 of the "Variable Size Integer". Thus a "Variable Size Integer" of 1 376 octet length supplies 7 bits for "VINT_DATA", a 2 octet length 377 supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21 378 bits for "VINT_DATA". If the number of bits required for "VINT_DATA" 379 are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be 380 zero-padded to the left to a size that fits. The "VINT_DATA" value 381 MUST be expressed as a big-endian unsigned integer. 383 5.4. VINT Examples 385 This table shows examples of "Variable Size Integers" with lengths 386 from 1 to 5 octets. The Size column refers to the size of the 387 "VINT_DATA" in bits. The Representation column depicts a binary 388 expression of "Variable Size Integers" where "VINT_WIDTH" is depicted 389 by '0', the "VINT_MARKER" as '1', and the "VINT_DATA" as 'x'. 391 +-------------+------+----------------------------------------------+ 392 | Octet | Size | Representation | 393 | Length | | | 394 +-------------+------+----------------------------------------------+ 395 | 1 | 2^7 | 1xxx xxxx | 396 | 2 | 2^14 | 01xx xxxx xxxx xxxx | 397 | 3 | 2^21 | 001x xxxx xxxx xxxx xxxx xxxx | 398 | 4 | 2^28 | 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 399 | 5 | 2^35 | 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 400 | | | xxxx | 401 +-------------+------+----------------------------------------------+ 403 Data encoded as a "Variable Size Integer" MAY be rendered at octet 404 lengths larger than needed to store the data. In this table a binary 405 value of "0b10" is shown encoded as different "Variable Size 406 Integers" with lengths from one octet to four octet. All four 407 encoded examples have identical semantic meaning though the 408 "VINT_WIDTH" and the padding of the "VINT_DATA" vary. 410 +--------------+--------------+-------------------------------------+ 411 | Binary Value | Octet Length | As Represented in Variable Size | 412 | | | Integer | 413 +--------------+--------------+-------------------------------------+ 414 | 10 | 1 | 1000 0010 | 415 | 10 | 2 | 0100 0000 0000 0010 | 416 | 10 | 3 | 0010 0000 0000 0000 0000 0010 | 417 | 10 | 4 | 0001 0000 0000 0000 0000 0000 0000 | 418 | | | 0010 | 419 +--------------+--------------+-------------------------------------+ 421 6. Element ID 423 The "Element ID" MUST be encoded as a "Variable Size Integer". By 424 default, "Element IDs" are encoded in lengths from one octet to four 425 octets, although "Element IDs" of greater lengths are used if the 426 octet length of the longest "Element ID" of the "EBML Document" is 427 declared in the "EBMLMaxIDLength Element" of the "EBML Header" (see 428 Section 13.2.4). The "VINT_DATA" component of the "Element ID" MUST 429 NOT be either defined or written as either all zero values or all one 430 values. Any "Element ID" with the "VINT_DATA" component set as all 431 zero values or all one values MUST be ignored and MUST NOT be 432 considered an error in the "EBML Document". The "VINT_DATA" 433 component of the "Element ID" MUST be encoded at the shortest valid 434 length. For example, an "Element ID" with binary encoding of "1011 435 1111" is valid, whereas an "Element ID" with binary encoding of "0100 436 0000 0011 1111" stores a semantically equal "VINT_DATA" but is 437 invalid because a shorter "VINT" encoding is possible. Additionally, 438 an "Element ID" with binary encoding of "1111 1111" is invalid since 439 the "VINT_DATA" section is set to all one values, whereas an "Element 440 ID" with binary encoding of "0100 0000 0111 1111" stores a 441 semantically equal "VINT_DATA" and is the shortest possible "VINT" 442 encoding. 444 The following table details these specific examples further: 446 +------------+-------------+----------------+-----------------------+ 447 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status | 448 +------------+-------------+----------------+-----------------------+ 449 | | 1 | 0000000 | Invalid: "VINT_DATA" | 450 | | | | MUST NOT be set to | 451 | | | | all 0 | 452 | 0 | 1 | 00000000000000 | Invalid: "VINT_DATA" | 453 | | | | MUST NOT be set to | 454 | | | | all 0 | 455 | | 1 | 0000001 | Valid | 456 | 0 | 1 | 00000000000001 | Invalid: A shorter | 457 | | | | "VINT_DATA" encoding | 458 | | | | is available. | 459 | | 1 | 0111111 | Valid | 460 | 0 | 1 | 00000000111111 | Invalid: A shorter | 461 | | | | "VINT_DATA" encoding | 462 | | | | is available. | 463 | | 1 | 1111111 | Invalid: "VINT_DATA" | 464 | | | | MUST NOT be set to | 465 | | | | all 1 | 466 | 0 | 1 | 00000001111111 | Valid | 467 +------------+-------------+----------------+-----------------------+ 469 The octet length of an "Element ID" determines its "EBML Class". 471 +------------+--------------+--------------------------------+ 472 | EBML Class | Octet Length | Number of Possible Element IDs | 473 +------------+--------------+--------------------------------+ 474 | Class A | 1 | 2^7 - 2 = 126 | 475 | Class B | 2 | 2^14 - 2^7 - 1 = 16,255 | 476 | Class C | 3 | 2^21 - 2^14 - 1 = 2,080,767 | 477 | Class D | 4 | 2^28 - 2^21 - 1 = 266,338,303 | 478 +------------+--------------+--------------------------------+ 480 7. Element Data Size 482 The "Element Data Size" expresses the length in octets of "Element 483 Data". The "Element Data Size" itself MUST be encoded as a "Variable 484 Size Integer". By default, "Element Data Sizes" can be encoded in 485 lengths from one octet to eight octets, although "Element Data Sizes" 486 of greater lengths MAY be used if the octet length of the longest 487 "Element Data Size" of the "EBML Document" is declared in the 488 "EBMLMaxSizeLength Element" of the "EBML Header" (see 489 Section 13.2.5). Unlike the "VINT_DATA" of the "Element ID", the 490 "VINT_DATA" component of the "Element Data Size" is not mandated to 491 be encoded at the shortest valid length. For example, an "Element 492 Data Size" with binary encoding of "1011 1111" or a binary encoding 493 of "0100 0000 0011 1111" are both valid "Element Data Sizes" and both 494 store a semantically equal value (both "0b00000000111111" and 495 "0b0111111", the "VINT_DATA" sections of the examples, represent the 496 integer 63). 498 Although an "Element ID" with all "VINT_DATA" bits set to zero is 499 invalid, an "Element Data Size" with all "VINT_DATA" bits set to zero 500 is allowed for "EBML Element Types" which do not mandate a non-zero 501 length (see Section 8). An "Element Data Size" with all "VINT_DATA" 502 bits set to zero indicates that the "Element Data" is zero octets in 503 length. Such an "EBML Element" is referred to as an "Empty Element". 504 If an "Empty Element" has a "default" value declared then the "EBML 505 Reader" MUST interpret the value of the "Empty Element" as the 506 "default" value. If an "Empty Element" has no "default" value 507 declared then the "EBML Reader" MUST interpret the value of the 508 "Empty Element" as defined as part of the definition of the 509 corresponding "EBML Element Type" associated with the "Element ID". 511 An "Element Data Size" with all "VINT_DATA" bits set to one is 512 reserved as an indicator that the size of the "EBML Element" is 513 unknown. The only reserved value for the "VINT_DATA" of "Element 514 Data Size" is all bits set to one. An "EBML Element" with an unknown 515 "Element Data Size" is referred to as an "Unknown-Sized Element". 516 Only "Master Elements" SHALL be "Unknown-Sized Elements". "Master 517 Elements" MUST NOT use an unknown size unless the 518 "unknownsizeallowed" attribute of their "EBML Schema" is set to true 519 (see Section 13.1.4.10). The use of "Unknown-Sized Elements" allows 520 for an "EBML Element" to be written and read before the size of the 521 "EBML Element" is known. "Unknown-Sized Element" MUST NOT be used or 522 defined unnecessarily; however if the "Element Data Size" is not 523 known before the "Element Data" is written, such as in some cases of 524 data streaming, then "Unknown-Sized Elements" MAY be used. The end 525 of an "Unknown-Sized Element" is determined by whichever comes first: 526 the end of the file or the beginning of the next "EBML Element", 527 defined by this document or the corresponding "EBML Schema", that is 528 not independently valid as "Descendant Element" of the "Unknown-Sized 529 Element". 531 For "Element Data Sizes" encoded at octet lengths from one to eight, 532 this table depicts the range of possible values that can be encoded 533 as an "Element Data Size". An "Element Data Size" with an octet 534 length of 8 is able to express a size of 2^56-2 or 535 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum 536 possible value that can be stored as "Element Data Size" is referred 537 to as "VINTMAX". 539 +--------------+----------------------+ 540 | Octet Length | Possible Value Range | 541 +--------------+----------------------+ 542 | 1 | 0 to 2^7-2 | 543 | 2 | 0 to 2^14-2 | 544 | 3 | 0 to 2^21-2 | 545 | 4 | 0 to 2^28-2 | 546 | 5 | 0 to 2^35-2 | 547 | 6 | 0 to 2^42-2 | 548 | 7 | 0 to 2^49-2 | 549 | 8 | 0 to 2^56-2 | 550 +--------------+----------------------+ 552 If the length of "Element Data" equals "2^(n*7)-1" then the octet 553 length of the "Element Data Size" MUST be at least "n+1". This rule 554 prevents an "Element Data Size" from being expressed as a reserved 555 value. For example, an "EBML Element" with an octet length of 127 556 MUST NOT be encoded in an "Element Data Size" encoding with a one 557 octet length. The following table clarifies this rule by showing a 558 valid and invalid expression of an "Element Data Size" with a 559 "VINT_DATA" of 127 (which is equal to 2^(1*7)-1). 561 +------------+-------------+----------------+-----------------------+ 562 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element Data Size | 563 | | | | Status | 564 +------------+-------------+----------------+-----------------------+ 565 | | 1 | 1111111 | Reserved (meaning | 566 | | | | Unknown) | 567 | 0 | 1 | 00000001111111 | Valid (meaning 127 | 568 | | | | octets) | 569 +------------+-------------+----------------+-----------------------+ 571 8. EBML Element Types 573 "EBML Elements" are defined by an "EBML Schema" which MUST declare 574 one of the following "EBML Element Types" for each "EBML Element". 575 An "EBML Element Type" defines a concept of storing data within an 576 "EBML Element" that describes such characteristics as length, 577 endianness, and definition. 579 "EBML Elements" which are defined as a "Signed Integer Element", 580 "Unsigned Integer Element", "Float Element", or "Date Element" use 581 big endian storage. 583 8.1. Signed Integer Element 585 A "Signed Integer Element" MUST declare a length from zero to eight 586 octets. If the "EBML Element" is not defined to have a "default" 587 value, then a "Signed Integer Element" with a zero-octet length 588 represents an integer value of zero. 590 A "Signed Integer Element" stores an integer (meaning that it can be 591 written without a fractional component) which could be negative, 592 positive, or zero. Signed Integers MUST be stored with two's 593 complement notation with the leftmost bit being the sign bit. 594 Because "EBML" limits Signed Integers to 8 octets in length a "Signed 595 Integer Element" stores a number from -9,223,372,036,854,775,808 to 596 +9,223,372,036,854,775,807. 598 8.2. Unsigned Integer Element 600 An "Unsigned Integer Element" MUST declare a length from zero to 601 eight octets. If the "EBML Element" is not defined to have a 602 "default" value, then an "Unsigned Integer Element" with a zero-octet 603 length represents an integer value of zero. 605 An "Unsigned Integer Element" stores an integer (meaning that it can 606 be written without a fractional component) which could be positive or 607 zero. Because "EBML" limits Unsigned Integers to 8 octets in length 608 an "Unsigned Integer Element" stores a number from 0 to 609 18,446,744,073,709,551,615. 611 8.3. Float Element 613 A "Float Element" MUST declare a length of either zero octets (0 614 bit), four octets (32 bit) or eight octets (64 bit). If the "EBML 615 Element" is not defined to have a "default" value, then a "Float 616 Element" with a zero-octet length represents a numerical value of 617 zero. 619 A "Float Element" stores a floating-point number as defined in 620 [IEEE.754.1985]. 622 8.4. String Element 624 A "String Element" MUST declare a length in octets from zero to 625 "VINTMAX". If the "EBML Element" is not defined to have a "default" 626 value, then a "String Element" with a zero-octet length represents an 627 empty string. 629 A "String Element" MUST either be empty (zero-length) or contain 630 printable ASCII characters [RFC0020] in the range of "0x20" to 631 "0x7E", with an exception made for termination (see Section 9). 633 8.5. UTF-8 Element 635 A "UTF-8 Element" MUST declare a length in octets from zero to 636 "VINTMAX". If the "EBML Element" is not defined to have a "default" 637 value, then a "UTF-8 Element" with a zero-octet length represents an 638 empty string. 640 A "UTF-8 Element" contains only a valid Unicode string as defined in 641 [RFC3629], with an exception made for termination (see Section 9). 643 8.6. Date Element 645 A "Date Element" MUST declare a length of either zero octets or eight 646 octets. If the "EBML Element" is not defined to have a "default" 647 value, then a "Date Element" with a zero-octet length represents a 648 timestamp of 2001-01-01T00:00:00.000000000 UTC [RFC3339]. 650 The "Date Element" stores an integer in the same format as the 651 "Signed Integer Element" that expresses a point in time referenced in 652 nanoseconds from the precise beginning of the third millennium of the 653 Gregorian Calendar in Coordinated Universal Time (also known as 654 2001-01-01T00:00:00.000000000 UTC). This provides a possible 655 expression of time from 1708-09-11T00:12:44.854775808 UTC to 656 2293-04-11T11:47:16.854775807 UTC. 658 8.7. Master Element 660 A "Master Element" MUST declare a length in octets from zero to 661 "VINTMAX". The "Master Element" MAY also use an unknown length. See 662 Section 7 for rules that apply to elements of unknown length. 664 The "Master Element" contains zero, one, or many other elements. 665 "EBML Elements" contained within a "Master Element" MUST have the 666 "EBMLParentPath" of their "Element Path" equals to the 667 "EBMLReferencePath" of the "Master Element" "Element Path" (see 668 Section 13.1.4.2). "Element Data" stored within "Master Elements" 669 SHOULD only consist of "EBML Elements" and SHOULD NOT contain any 670 data that is not part of an "EBML Element". When "EBML" is used in 671 transmission or streaming, data that is not part of an "EBML Element" 672 is permitted to be present within a "Master Element" if 673 "unknownsizeallowed" is enabled within the definition for that 674 "Master Element". In this case, the "EBML Reader" should skip data 675 until a valid "Element ID" of the same "EBMLParentPath" or the next 676 upper level "Element Path" of the "Master Element" is found. What 677 "Element IDs" are considered valid within a "Master Element" is 678 identified by the "EBML Schema" for that version of the "EBML 679 Document Type". Any data contained within a "Master Element" that is 680 not part of a "Child Element" MUST be ignored. 682 8.8. Binary Element 684 A "Binary Element" MUST declare a length in octets from zero to 685 "VINTMAX". 687 The contents of a "Binary Element" should not be interpreted by the 688 "EBML Reader". 690 9. Terminating Elements 692 "Null Octets", which are octets with all bits set to zero, MAY follow 693 the value of a "String Element" or "UTF-8 Element" to serve as a 694 terminator. An "EBML Writer" MAY terminate a "String Element" or 695 "UTF-8 Element" with "Null Octets" in order to overwrite a stored 696 value with a new value of lesser length while maintaining the same 697 "Element Data Size" (this can prevent the need to rewrite large 698 portions of an "EBML Document"); otherwise the use of "Null Octets" 699 within a "String Element" or "UTF-8 Element" is NOT RECOMMENDED. An 700 "EBML Reader" MUST consider the value of the "String Element" or 701 "UTF-8 Element" to be terminated upon the first read "Null Octet" and 702 MUST ignore any data following the first "Null Octet" within that 703 "Element". A string value and a copy of that string value terminated 704 by one or more "Null Octets" are semantically equal. 706 The following table shows examples of semantics and validation for 707 the use of "Null Octets". Values to represent "Stored Values" and 708 the "Semantic Meaning" as represented as hexadecimal values. 710 +---------------------+---------------------+ 711 | Stored Value | Semantic Meaning | 712 +---------------------+---------------------+ 713 | 0x65 0x62 0x6d 0x6c | 0x65 0x62 0x6d 0x6c | 714 | 0x65 0x62 0x00 0x6c | 0x65 0x62 | 715 | 0x65 0x62 0x00 0x00 | 0x65 0x62 | 716 | 0x65 0x62 | 0x65 0x62 | 717 +---------------------+---------------------+ 719 10. Guidelines for Updating Elements 721 An EBML Document can be updated without requiring that the entire 722 EBML Document be rewritten. These recommendations describe 723 strategies to change the "Element Data" of a written "EBML Element" 724 with minimal disruption to the rest of the "EBML Document". 726 10.1. Reducing a Element Data in Size 728 There are three methods to reduce the size of "Element Data" of a 729 written "EBML Element". 731 10.1.1. Adding a Void Element 733 When an "EBML Element" is changed to reduce its total length by more 734 than one octet, an "EBML Writer" SHOULD fill the freed space with a 735 "Void Element". 737 10.1.2. Extending the Element Data Size 739 The same value for "Element Data Size" MAY be written in variable 740 lengths, so for minor reductions in octet length the "Element Data 741 Size" MAY be written to a longer octet length to fill the freed 742 space. 744 For example, the first row of the following table depicts a "String 745 Element" that stores an "Element ID" (3 octets), "Element Data Size" 746 (1 octet), and "Element Data" (4 octets). If the "Element Data" is 747 changed to reduce the length by one octet and if the current length 748 of the "Element Data Size" is less than its maximum permitted length, 749 then the "Element Data Size" of that "Element" MAY be rewritten to 750 increase its length by one octet. Thus before and after the change 751 the "EBML Element" maintains the same length of 8 octets and data 752 around the "Element" does not need to be moved. 754 +-------------+------------+-------------------+--------------+ 755 | Status | Element ID | Element Data Size | Element Data | 756 +-------------+------------+-------------------+--------------+ 757 | Before edit | 0x3B4040 | 0x84 | 0x65626d6c | 758 | After edit | 0x3B4040 | 0x4003 | 0x6d6b76 | 759 +-------------+------------+-------------------+--------------+ 761 This method is only RECOMMENDED for reducing "Element Data" by a 762 single octet; for reductions by two or more octets it is RECOMMENDED 763 to fill the freed space with a "Void Element". 765 Note that if the "Element Data" length needs to be rewritten as 766 shortened by one octet and the "Element Data Size" could be rewritten 767 as a shorter "VINT" then it is RECOMMENDED to rewrite the "Element 768 Data Size" as one octet shorter, shorten the "Element Data" by one 769 octet, and follow that "Element" with a "Void Element". For example, 770 the following table depicts a "String Element" that stores an 771 "Element ID" (3 octets), "Element Data Size" (2 octets, but could be 772 rewritten in one octet), and "Element Data" (3 octets). If the 773 "Element Data" is to be rewritten to a two octet length, then another 774 octet can be taken from "Element Data Size" so that there is enough 775 space to add a two octet "Void Element". 777 +--------+------------+-----------------+-------------+-------------+ 778 | Status | Element ID | Element Data | Element | Void | 779 | | | Size | Data | Element | 780 +--------+------------+-----------------+-------------+-------------+ 781 | Before | 0x3B4040 | 0x4003 | 0x6d6b76 | | 782 | After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 | 783 +--------+------------+-----------------+-------------+-------------+ 785 10.1.3. Terminating Element Data 787 For "String Elements" and "UTF-8 Elements" the length of "Element 788 Data" MAY be reduced by adding "Null Octets" to terminate the 789 "Element Data" (see Section 9). 791 In the following table, a four octet long "Element Data" is changed 792 to a three octet long value followed by a "Null Octet"; the "Element 793 Data Size" includes any "Null Octets" used to terminate "Element 794 Data" so remains unchanged. 796 +-------------+------------+-------------------+--------------+ 797 | Status | Element ID | Element Data Size | Element Data | 798 +-------------+------------+-------------------+--------------+ 799 | Before edit | 0x3B4040 | 0x84 | 0x65626d6c | 800 | After edit | 0x3B4040 | 0x84 | 0x6d6b7600 | 801 +-------------+------------+-------------------+--------------+ 803 Note that this method is NOT RECOMMENDED. For reductions of one 804 octet, the method for "Extending the Element Data Size" SHOULD be 805 used. For reduction by more than one octet, the method for "Adding a 806 Void Element" SHOULD be used. 808 10.2. Considerations when Updating Elements with CRC 810 If the "Element" to be changed is a "Descendant Element" of any 811 "Master Element" that contains an "CRC-32 Element" then the "CRC-32 812 Element" MUST be verified before permitting the change. Additionally 813 the "CRC-32 Element" value MUST be subsequently updated to reflect 814 the changed data. 816 11. EBML Document 818 An "EBML Document" is comprised of only two components, an "EBML 819 Header" and an "EBML Body". An "EBML Document" MUST start with an 820 "EBML Header" that declares significant characteristics of the entire 821 "EBML Body". An "EBML Document" consists of "EBML Elements" and MUST 822 NOT contain any data that is not part of an "EBML Element". 824 11.1. EBML Header 826 The "EBML Header" is a declaration that provides processing 827 instructions and identification of the "EBML Body". The "EBML 828 Header" of an "EBML Document" is analogous to the XML Declaration of 829 an XML Document. 831 The "EBML Header" documents the "EBML Schema" (also known as the 832 "EBML DocType") that is used to semantically interpret the structure 833 and meaning of the "EBML Document". Additionally the "EBML Header" 834 documents the versions of both "EBML" and the "EBML Schema" that were 835 used to write the "EBML Document" and the versions required to read 836 the "EBML Document". 838 The "EBML Header" MUST contain a single "Master Element" with an 839 "Element Name" of "EBML" and "Element ID" of "0x1A45DFA3" (see 840 Section 13.2.1) and any number of additional "EBML Elements" within 841 it. The "EBML Header" of an "EBML Document" that uses an 842 "EBMLVersion" of "1" MUST only contain "EBML Elements" that are 843 defined as part of this document. 845 All "EBML Elements" within the "EBML Header" MUST NOT use any 846 "Element ID" with a length greater than 4 octets. All "EBML 847 Elements" within the "EBML Header" MUST NOT use any "Element Data 848 Size" with a length greater than 4 octets. 850 11.2. EBML Body 852 All data of an "EBML Document" following the "EBML Header" is the 853 "EBML Body". The end of the "EBML Body", as well as the end of the 854 "EBML Document" that contains the "EBML Body", is considered as 855 whichever comes first: the beginning of a new "EBML Header" at the 856 "Root Level" or the end of the file. The "EBML Body" MUST consist 857 only of "EBML Elements" and MUST NOT contain any data that is not 858 part of an "EBML Element". This document defines precisely what 859 "EBML Elements" are to be used within the "EBML Header", but does not 860 name or define what "EBML Elements" are to be used within the "EBML 861 Body". The definition of what "EBML Elements" are to be used within 862 the "EBML Body" is defined by an "EBML Schema". 864 12. EBML Stream 866 An "EBML Stream" is a file that consists of one or many "EBML 867 Documents" that are concatenated together. An occurrence of a "EBML 868 Header" at the "Root Level" marks the beginning of an "EBML 869 Document". 871 13. Elements semantic 873 13.1. EBML Schema 875 An "EBML Schema" is an XML Document that defines the properties, 876 arrangement, and usage of "EBML Elements" that compose a specific 877 "EBML Document Type". The relationship of an "EBML Schema" to an 878 "EBML Document" may be considered analogous to the relationship of an 879 XML Schema [W3C.REC-xmlschema-0-20010502] to an XML Document 880 [W3C.REC-xml-20081126]. An "EBML Schema" MUST be clearly associated 881 with one or many "EBML Document Types". An "EBML Schema" must be 882 expressed as well-formed XML. An "EBML Document Type" is identified 883 by a string stored within the "EBML Header" in the "DocType Element"; 884 for example "matroska" or "webm" (see Section 13.2.6). The "DocType" 885 value for an "EBML Document Type" SHOULD be unique and persistent. 887 An "EBML Schema" MUST declare exactly one "EBML Element" at "Root 888 Level" (referred to as the "Root Element") that MUST occur exactly 889 once within an "EBML Document". The "Void Element" MAY also occur at 890 "Root Level" but is not considered to be "Root Elements" (see 891 Section 13.3.2). 893 The "EBML Schema" MUST document all Elements of the "EBML Body". The 894 "EBML Schema" does not document "Global Elements" that are defined by 895 this document (namely the "Void Element" and the "CRC-32 Element"). 897 An "EBML Schema" MAY constrain the use of "EBML Header Elements" (see 898 Section 13.2) by adding or constraining that Element's "range" 899 attribute. For example, an "EBML Schema" MAY constrain the 900 "EBMLMaxSizeLength" to a maximum value of "8" or MAY constrain the 901 "EBMLVersion" to only support a value of "1". If an "EBML Schema" 902 adopts the "EBML Header Element" as-is, then it is not REQUIRED to 903 document that Element within the "EBML Schema". If an "EBML Schema" 904 constrains the range of an "EBML Header Element", then that "Element" 905 MUST be documented within an "" node of the "EBML Schema". 906 This document provides an example of an "EBML Schema", see 907 Section 13.1.11. 909 13.1.1. Element 911 As an XML Document, the "EBML Schema" MUST use "" as the 912 top level element. The "" element MAY contain 913 "" sub-elements. 915 13.1.2. Attributes 917 Within an "EBML Schema" the "" element uses the following 918 attributes: 920 13.1.2.1. docType 922 The "docType" lists the official name of the "EBML Document Type" 923 that is defined by the "EBML Schema"; for example, "". 926 The "docType" attribute is REQUIRED within the "" 927 Element. 929 13.1.2.2. version 931 The "version" lists an incremental non-negative integer that 932 specifies the version of the docType documented by the "EBML Schema". 933 Unlike XML Schemas, an "EBML Schema" documents all versions of a 934 docType's definition rather than using separate "EBML Schemas" for 935 each version of a "docType". "EBML Elements" may be introduced and 936 deprecated by using the "minver" and "maxver" attributes of 937 "". 939 The "version" attribute is REQUIRED within the "" 940 Element. 942 13.1.3. Element 944 Each "" defines one "EBML Element" through the use of 945 several attributes that are defined in Section 13.1.2. "EBML 946 Schemas" MAY contain additional attributes to extend the semantics 947 but MUST NOT conflict with the definitions of the "" 948 attributes defined within this document. 950 The "" nodes contain a description of the meaning and use of 951 the "EBML Element" stored within one or many "" sub- 952 elements and zero or one "" sub-element. All 953 "" nodes MUST be sub-elements of the "". 955 13.1.4. Attributes 957 Within an "EBML Schema" the "" uses the following attributes 958 to define an "EBML Element": 960 13.1.4.1. name 962 The "name" provides the official human-readable name of the "EBML 963 Element". The value of the name MUST be in the form of characters 964 "A" to "Z", "a" to "z", "0" to "9", "-" and ".". 966 The "name" attribute is REQUIRED. 968 13.1.4.2. path 970 The path defines the allowed storage locations of the "EBML Element" 971 within an "EBML Document". This path MUST be defined with the full 972 hierarchy of "EBML Elements" separated with a "/". The top "EBML 973 Element" in the path hierarchy being the first in the value. The 974 syntax of the "path" attribute is defined using this Augmented 975 Backus-Naur Form (ABNF) [RFC5234] with the case sensitive update 976 [RFC7405] notation: 978 The "path" attribute is REQUIRED. 980 EBMLFullPath = EBMLElementOccurrence "(" EBMLReferencePath ")" 981 EBMLReferencePath = [EBMLParentPath] EBMLElementPath 982 EBMLParentPath = EBMLFixedParent EBMLLastParent 983 EBMLFixedParent = *(EBMLPathAtom) 984 EBMLElementPath = EBMLPathAtom / EBMLPathAtomRecursive 985 EBMLPathAtom = PathDelimiter EBMLAtomName 986 EBMLPathAtomRecursive = "(1*(" EBMLPathAtom "))" 987 EBMLLastParent = EBMLPathAtom / EBMLVariableParent 988 EBMLVariableParent = "(" VariableParentOccurrence "\)" 989 EBMLAtomName = 1*(EBMLNameChar) 990 EBMLNameChar = ALPHA / DIGIT / "-" / "." 991 PathDelimiter = "\" 992 EBMLElementOccurrence = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence] 993 EBMLMinOccurrence = 1*DIGIT 994 EBMLMaxOccurrence = 1*DIGIT 995 VariableParentOccurrence = [PathMinOccurrence] "*" [PathMaxOccurrence] 996 PathMinOccurrence = 1*DIGIT 997 PathMaxOccurrence = 1*DIGIT 999 The ""*"", ""("" and "")"" symbols MUST be interpreted as they are 1000 defined in the ABNF. 1002 The "EBMLPathAtom" part of the "EBMLElementPath" MUST be equal to the 1003 "name" attribute of the "EBML Schema". 1005 The starting "PathDelimiter" of the path corresponds to the root of 1006 the "EBML Document". 1008 The "EBMLElementOccurrence" part is interpreted as an ABNF Variable 1009 Repetition. The repetition amounts correspond to how many times the 1010 "EBML Element" can be found in its "Parent Element". 1012 The "EBMLMinOccurrence" represents the minimum number of occurrences 1013 of this "EBML Element" within its "Parent Element". Each instance of 1014 the "Parent Element" MUST contain at least this many instances of 1015 this "EBML Element". If the "EBML Element" has an empty 1016 "EBMLParentPath" then "EBMLMinOccurrence" refers to constraints on 1017 the occurrence of the "EBML Element" within the "EBML Document". If 1018 "EBMLMinOccurrence" is not present then that "EBML Element" is 1019 considered to have a "EBMLMinOccurrence" value of 0. The semantic 1020 meaning of "EBMLMinOccurrence" within an "EBML Schema" is considered 1021 analogous to the meaning of "minOccurs" within an "XML Schema". 1022 "EBML Elements" with "EBMLMinOccurrence" set to "1" that also have a 1023 "default" value (see Section 13.1.4.8) declared are not REQUIRED to 1024 be stored but are REQUIRED to be interpreted, see Section 13.1.15. 1025 An "EBML Element" defined with a "EBMLMinOccurrence" value greater 1026 than zero is called a "Mandatory EBML Element". 1028 The "EBMLMaxOccurrence" represents the maximum number of occurrences 1029 of this "EBML Element" within its "Parent Element". Each instance of 1030 the "Parent Element" MUST contain at most this many instances of this 1031 "EBML Element". If the "EBML Element" has an empty "EBMLParentPath" 1032 then "EBMLMaxOccurrence" refers to constraints on the occurrence of 1033 the "EBML Element" within the "EBML Document". If 1034 "EBMLMaxOccurrence" is not present then that "EBML Element" is 1035 considered to have no maximum occurrence. The semantic meaning of 1036 "EBMLMaxOccurrence" within an "EBML Schema path" is considered 1037 analogous to the meaning of "maxOccurs" within an "XML Schema". 1039 The "VariableParentOccurrence" part is interpreted as an ABNF 1040 Variable Repetition. The repetition amounts correspond to the amount 1041 of unspecified "Parent Element" levels there can be between the 1042 "EBMLFixedParent" and the actual "EBMLElementPath". 1044 If the path contains an "EBMLPathAtomRecursive" part, the "EBML 1045 Element" can occur within itself recursively (see the 1046 Section 13.1.4.11). 1048 13.1.4.3. id 1050 The "Element ID" encoded as a "Variable Size Integer" expressed in 1051 hexadecimal notation prefixed by a "0x" that is read and stored in 1052 big-endian order. To reduce the risk of false positives while 1053 parsing "EBML Streams", the "Element IDs" of the "Root Element" and 1054 "Top-Level Elements" SHOULD be at least 4 octets in length. "Element 1055 IDs" defined for use at "Root Level" or directly under the "Root 1056 Level" MAY use shorter octet lengths to facilitate padding and 1057 optimize edits to "EBML Documents"; for instance, the "Void Element" 1058 uses an "Element ID" with a one octet length to allow its usage in 1059 more writing and editing scenarios. 1061 The "id" attribute is REQUIRED. 1063 13.1.4.4. minOccurs 1065 An integer expressing the minimum number of occurrences of this "EBML 1066 Element" within its "Parent Element". The "minOccurs" value MUST be 1067 equal to the "EBMLMinOccurrence" value of the "path". 1069 The "minOccurs" attribute is OPTIONAL. If the "minOccurs" attribute 1070 is not present then that "EBML Element" is considered to have a 1071 "minOccurs" value of 0. 1073 13.1.4.5. maxOccurs 1075 An integer expressing the maximum number of occurrences of this "EBML 1076 Element" within its "Parent Element". The "maxOccurs" value MUST be 1077 equal to the "EBMLMaxOccurrence" value of the "path". 1079 The "maxOccurs" attribute is OPTIONAL. If the "maxOccurs" attribute 1080 is not present then that "EBML Element" is considered to have no 1081 maximum occurrence, similar to "unbounded" in the XML world. 1083 13.1.4.6. range 1085 A numerical range for "EBML Elements" which are of numerical types 1086 (Unsigned Integer, Signed Integer, Float, and Date). If specified 1087 the value of the "EBML Element" MUST be within the defined range. 1088 See Section 13.1.13 for rules applied to expression of range values. 1090 The "range" attribute is OPTIONAL. If the "range" attribute is not 1091 present then any value legal for the "type" attribute is valid. 1093 13.1.4.7. size 1095 A value to express the valid length of the "Element Data" as written 1096 measured in octets. The "size" provides a constraint in addition to 1097 the Length value of the definition of the corresponding "EBML Element 1098 Type". This "size" MUST be expressed as either a non-negative 1099 integer or a range (see Section 13.1.13) that consists of only non- 1100 negative integers and valid operators. 1102 The "size" attribute is OPTIONAL. If the "size" attribute is not 1103 present for that "EBML Element" then that "EBML Element" is only 1104 limited in size by the definition of the associated "EBML Element 1105 Type". 1107 13.1.4.8. default 1109 If an "Element" is mandatory (has a "EBMLMinOccurrence" value greater 1110 than zero) but not written within its "Parent Element" or stored as 1111 an "Empty Element", then the "EBML Reader" of the "EBML Document" 1112 MUST semantically interpret the "EBML Element" as present with this 1113 specified default value for the "EBML Element". "EBML Elements" that 1114 are "Master Elements" MUST NOT declare a "default" value. "EBML 1115 Elements" with a "minOccurs" value greater than 1 MUST NOT declare a 1116 "default" value. 1118 The "default" attribute is OPTIONAL. 1120 13.1.4.9. type 1122 The "type" MUST be set to one of the following values: 'integer' 1123 (signed integer), 'uinteger' (unsigned integer), 'float', 'string', 1124 'date', 'utf-8', 'master', or 'binary'. The content of each "type" 1125 is defined within Section 8. 1127 The "type" attribute is REQUIRED. 1129 13.1.4.10. unknownsizeallowed 1131 A boolean to express if an "EBML Element" MAY be used as an "Unknown- 1132 Sized Element" (having all "VINT_DATA" bits of "Element Data Size" 1133 set to 1). "EBML Elements" that are not "Master Elements" MUST NOT 1134 set "unknownsizeallowed" to true. An "EBML Element" that is defined 1135 with an "unknownsizeallowed" attribute set to 1 MUST also have the 1136 "unknownsizeallowed" attribute of its "Parent Element" set to 1. 1138 The "unknownsizeallowed" attribute is OPTIONAL. If the 1139 "unknownsizeallowed" attribute is not used then that "EBML Element" 1140 is not allowed to use an unknown "Element Data Size". 1142 13.1.4.11. recursive 1144 A boolean to express if an "EBML Element" MAY be stored recursively. 1145 In this case the "EBML Element" MAY be stored within another "EBML 1146 Element" that has the same "Element ID". Which itself can be stored 1147 in an "EBML Element" that has the same "Element ID", and so on. 1148 "EBML Elements" that are not "Master Elements" MUST NOT set 1149 "recursive" to true. 1151 If the "path" contains an "EBMLPathAtomRecursive" part then the 1152 "recursive" value MUST be true and false otherwise. 1154 The "recursive" attribute is OPTIONAL. If the "recursive" attribute 1155 is not present then the "EBML Element" MUST NOT be used recursively. 1157 13.1.4.12. recurring 1159 A boolean to express if an "EBML Element" is defined as an 1160 "Identically Recurring Element" or not. 1162 The "recurring" attribute is OPTIONAL. If the "recurring" attribute 1163 is not present then the "EBML Element" MUST be considered to NOT be 1164 an "Identically Recurring Element". 1166 13.1.4.13. minver 1168 The "minver" (minimum version) attribute stores a non-negative 1169 integer that represents the first version of the "docType" to support 1170 the "EBML Element". 1172 The "minver" attribute is OPTIONAL. If the "minver" attribute is not 1173 present, then the "EBML Element" has a minimum version of "1". 1175 13.1.4.14. maxver 1177 The "maxver" (maximum version) attribute stores a non-negative 1178 integer that represents the last or most recent version of the 1179 "docType" to support the element. "maxver" MUST be greater than or 1180 equal to "minver". 1182 The "maxver" attribute is OPTIONAL. If the "maxver" attribute is not 1183 present then the "EBML Element" has a maximum version equal to the 1184 value stored in the "version" attribute of "". 1186 13.1.5. Element 1188 The "" element provides additional information about 1189 the "EBML Element". 1191 13.1.6. Attributes 1193 13.1.6.1. lang 1195 A "lang" attribute which is set to the [RFC5646] value of the 1196 language of the element's documentation. 1198 The "lang" attribute is OPTIONAL. 1200 13.1.6.2. type 1202 A "type" attribute distinguishes the meaning of the documentation. 1203 Values for the "" sub-element's "type" attribute MUST 1204 include one of the following: "definition", "rationale", "usage 1205 notes", and "references". 1207 The "type" attribute is OPTIONAL. 1209 13.1.7. Element 1211 The "" element provides information about restrictions 1212 to the allowable values for the "EBML Element" which are listed in 1213 "" elements. 1215 13.1.8. Element 1217 The "" element stores a list of values allowed for storage in 1218 the "EBML Element". The values MUST match the "type" of the "EBML 1219 Element" (for example "" cannot be a valid value 1220 for a "EBML Element" that is defined as an unsigned integer). An 1221 "" element MAY also store "" elements to further 1222 describe the "". 1224 13.1.9. Attributes 1226 13.1.9.1. label 1228 The "label" provides a concise expression for human consumption that 1229 describes what the "value" of the "" represents. 1231 The "label" attribute is OPTIONAL. 1233 13.1.9.2. value 1235 The "value" represents data that MAY be stored within the "EBML 1236 Element". 1238 The "value" attribute is REQUIRED. 1240 13.1.10. XML Schema for EBML Schema 1242 1243 1247 1248 1249 1250 1252 1253 1254 1255 1256 1257 1258 1260 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1282 1283 1284 1285 1286 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1301 13.1.11. EBML Schema Example 1303 1304 1306 1307 1310 1313 1314 1315 Container of data and 1316 attributes representing one or many files. 1317 1318 1320 1321 An attached file. 1322 1323 1324 1327 1328 Filename of the attached file. 1329 1331 1332 1335 1336 MIME type of the file. 1337 1338 1339 1342 1343 Modification timestamp of the file. 1344 1345 1346 1348 1349 The data of the file. 1350 1351 1352 1354 13.1.12. Identically Recurring Elements 1356 An "Identically Recurring Element" is an "EBML Element" that MAY 1357 occur within its "Parent Element" more than once but that each 1358 recurrence within that "Parent Element" MUST be identical both in 1359 storage and semantics. "Identically Recurring Elements" are 1360 permitted to be stored multiple times within the same "Parent 1361 Element" in order to increase data resilience and optimize the use of 1362 "EBML" in transmission. For instance a pertinent "Top-Level Element" 1363 could be periodically resent within a data stream so that an "EBML 1364 Reader" which starts reading the stream from the middle could better 1365 interpret the contents. "Identically Recurring Elements" SHOULD 1366 include a "CRC-32 Element" as a "Child Element"; this is especially 1367 recommended when "EBML" is used for long-term storage or 1368 transmission. If a "Parent Element" contains more than one copy of 1369 an "Identically Recurring Element" which includes a "CRC-32 Element" 1370 as a "Child Element" then the first instance of the "Identically 1371 Recurring Element" with a valid CRC-32 value should be used for 1372 interpretation. If a "Parent Element" contains more than one copy of 1373 an "Identically Recurring Element" which does not contain a "CRC-32 1374 Element" or if "CRC-32 Elements" are present but none are valid then 1375 the first instance of the "Identically Recurring Element" should be 1376 used for interpretation. 1378 13.1.13. Expression of range 1380 The "range" attribute MUST only be used with "EBML Elements" that are 1381 either "signed integer", "unsigned integer", "float", or "date". The 1382 "range" expression may contain whitespace for readability but 1383 whitespace within a "range" expression MUST NOT convey meaning. The 1384 expression of the "range" MUST adhere to one of the following forms: 1386 o "x-y" where x and y are integers or floats and "y" MUST be greater 1387 than "x", meaning that the value MUST be greater than or equal to 1388 "x" and less than or equal to "y". "x" MUST be less than "y". 1390 o ">x" where "x" is an integer or float, meaning that the value MUST 1391 be greater than "x". 1393 o ">=x" where "x" is an integer or float, meaning that the value 1394 MUST be greater than or equal to "x". 1396 o "=4 1554 default: 4 1556 type: Unsigned Integer 1558 description: The "EBMLMaxIDLength Element" stores the maximum length 1559 in octets of the "Element IDs" to be found within the "EBML Body". 1560 An "EBMLMaxIDLength Element" value of four is RECOMMENDED, though 1561 larger values are allowed. 1563 13.2.5. EBMLMaxSizeLength Element 1565 name: "EBMLMaxSizeLength" 1567 path: "1*1(\EBML\EBMLMaxSizeLength)" 1569 id "0x42F3" 1571 minOccurs: 1 1573 maxOccurs: 1 1575 range: not 0 1577 default: 8 1579 type: Unsigned Integer 1581 description: The "EBMLMaxSizeLength Element" stores the maximum 1582 length in octets of the expression of all "Element Data Sizes" to be 1583 found within the "EBML Body". To be clear the "EBMLMaxSizeLength 1584 Element" documents the maximum 'length' of all "Element Data Size" 1585 expressions within the "EBML Body" and not the maximum 'value' of all 1586 "Element Data Size" expressions within the "EBML Body". "EBML 1587 Elements" that have an "Element Data Size" expression which is larger 1588 in octets than what is expressed by "EBMLMaxSizeLength ELEMENT" SHALL 1589 be considered invalid. 1591 13.2.6. DocType Element 1593 name: "DocType" 1595 path: "1*1(\EBML\DocType)" 1597 id "0x4282" 1599 minOccurs: 1 1601 maxOccurs: 1 1603 size: >0 1605 type: String 1607 description: A string that describes and identifies the content of 1608 the "EBML Body" that follows this "EBML Header". 1610 13.2.7. DocTypeVersion Element 1612 name: "DocTypeVersion" 1614 path: "1*1(\EBML\DocTypeVersion)" 1616 id "0x4287" 1618 minOccurs: 1 1620 maxOccurs: 1 1622 range: not 0 1624 default: 1 1626 type: Unsigned Integer 1628 description: The version of "DocType" interpreter used to create the 1629 "EBML Document". 1631 13.2.8. DocTypeReadVersion Element 1633 name: DocTypeReadVersion 1635 path: "1*1(\EBML\DocTypeReadVersion)" 1637 id "0x4285" 1639 minOccurs: 1 1641 maxOccurs: 1 1643 range: not 0 1645 default: 1 1647 type: Unsigned Integer 1649 description: The minimum "DocType" version an "EBML Reader" has to 1650 support to read this "EBML Document". The value of the 1651 "DocTypeReadVersion Element" MUST be less than or equal to the value 1652 of the "DocTypeVersion Element". 1654 13.2.9. DocTypeExtension Element 1656 name: "DocTypeExtension" 1658 path: "0*(\EBML\DocTypeExtension)" 1660 id "0x4281" 1662 minOccurs: 0 1664 type: "Master Element" 1666 description: A "DocTypeExtension" adds extra "Elements" to the main 1667 "DocType"+"DocTypeVersion" tuple it's attached to. An "EBML Reader" 1668 MAY know these extra "Elements" and how to use them. A 1669 "DocTypeExtension" MAY be used to iterate between experimental 1670 "Elements" before they are integrated in a regular "DocTypeVersion". 1671 Reading one "DocTypeExtension" version of a 1672 "DocType"+"DocTypeVersion" tuple doesn't imply one should be able to 1673 read upper values of this "DocTypeExtension". 1675 13.2.10. DocTypeExtensionName Element 1677 name: "DocTypeExtensionName" 1679 path: "1*1(\EBML\DocTypeExtension\Name)" 1681 id "0x4283" 1683 minOccurs: 1 1685 maxOccurs: 1 1687 size: >0 1689 type: String 1691 description: The name of the "DocTypeExtension" to identify it from 1692 other "DocTypeExtension" of the same "DocType"+"DocTypeVersion" 1693 tuple. A "DocTypeExtensionName" value MUST be unique within the 1694 "EBML Header". 1696 13.2.11. DocTypeExtensionVersion Element 1698 name: "DocTypeExtensionVersion" 1700 path: "1*1(\EBML\DocTypeExtension\Version)" 1701 id "0x4284" 1703 minOccurs: 1 1705 maxOccurs: 1 1707 range: not 0 1709 type: Unsigned Integer 1711 description: The version of the "DocTypeExtension". Different 1712 "DocTypeExtensionVersion" values of the same 1713 "DocType"+"DocTypeVersion"+"DocTypeExtensionName" tuple MAY contain 1714 completely different sets of extra "Elements". An "EBML Reader" MAY 1715 support multiple versions of the same "DocTypeExtension", only one or 1716 none. 1718 13.3. Global Elements 1720 EBML defines these "Global Elements" which MAY be stored within any 1721 "Master Element" of an "EBML Document" as defined by their "Element 1722 Path". 1724 13.3.1. CRC-32 Element 1726 name: CRC-32 1728 path: "*1((1*\)\CRC-32)" 1730 id: "0xBF" 1732 minOccurs: 0 1734 maxOccurs: 1 1736 size: 4 1738 type: Binary 1740 description: The "CRC-32 Element" contains a 32-bit Cyclic Redundancy 1741 Check value of all the "Element Data" of the "Parent Element" as 1742 stored except for the "CRC-32 Element" itself. When the "CRC-32 1743 Element" is present, the "CRC-32 Element" MUST be the first ordered 1744 "EBML Element" within its "Parent Element" for easier reading. All 1745 "Top-Level Elements" of an "EBML Document" that are "Master Elements" 1746 SHOULD include a "CRC-32 Element" as a "Child Element". The CRC in 1747 use is the IEEE-CRC-32 algorithm as used in the [ISO.3309.1979] 1748 standard and in section 8.1.1.6.2 of [ITU.V42.1994], with initial 1749 value of "0xFFFFFFFF". The CRC value MUST be computed on a little 1750 endian bitstream and MUST use little endian storage. 1752 13.3.2. Void Element 1754 name: Void 1756 path: "*((*\)\Void)" 1758 id: "0xEC" 1760 minOccurs: 0 1762 type: Binary 1764 description: Used to void damaged data, to avoid unexpected behaviors 1765 when using damaged data. The content is discarded. Also used to 1766 reserve space in a sub-element for later use. 1768 14. Considerations for Reading EBML Data 1770 The following scenarios describe events to consider when reading 1771 "EBML Documents" and the recommended design of an "EBML Reader". 1773 If a "Master Element" contains a "CRC-32 Element" that doesn't 1774 validate, then the "EBML Reader" MAY ignore all contained data except 1775 for "Descendant Elements" which contain their own valid "CRC-32 1776 Element". 1778 If a "Master Element" contains more occurrences of a "Child Master 1779 Element" than permitted according to the "maxOccurs" and "recurring" 1780 attributes of the definition of that "Element" then the occurrences 1781 in addition to "maxOccurs" MAY be ignored. 1783 If a "Master Element" contains more occurrences of a "Child Element" 1784 that is not a "Master Element" than permitted according to the 1785 "maxOccurs" attribute of the definition of that "Element" then all 1786 but the instance of that "Element" with the smallest byte offset from 1787 the beginning of its "Parent Element" SHOULD be ignored. 1789 15. IANA Considerations 1791 15.1. CELLAR EBML Element ID Registry 1793 This document creates a new IANA Registry called "CELLAR EBML Element 1794 ID Registry". 1796 Element IDs are described in section "Element ID". Element IDs are 1797 encoded using the VINT mechanism described in section Section 5 can 1798 be between one and five octets long. Five octet long Element IDs are 1799 possible only if declared in the header. 1801 This IANA Registry only applies to "Elements" contained at least in 1802 the "EBML Header", thus including "Global Elements". "Elements" only 1803 found in the "EBML Body" have their own set of independent "Element 1804 IDs" and are not part of this IANA Registry. 1806 The VINT Data value of one-octet Element IDs MUST be between 0x01 and 1807 0x7E. These items are valuable because they are short, and need to 1808 be used for commonly repeated elements. Values from 1 to 126 are to 1809 be allocated according to RFC Required. 1811 The VINT Data value of two-octet Element IDs MUST be between 0x007F 1812 and 0x3FFE. Numbers MAY be allocated within this range according to 1813 Specification Required. 1815 The numbers 0x3FFF and 0x4000 are RESERVED. 1817 The VINT Data value of three-octet Element IDs MUST be between 0x4001 1818 and 0x1FFFFE. Numbers may be allocated within this range according 1819 to First Come First Served (see [RFC8126]) 1821 The numbers 0x1FFFFF and 0x200000 are RESERVED. 1823 Four octet Element IDs are numbers between 0x2000001 and 0xFFFFFFE. 1824 Four octet Element IDs are somewhat special in that they are useful 1825 for resynchronizing to major structures in the event of data 1826 corruption or loss. As such four octet Element IDs are split into 1827 two categories. Four octet Element IDs whose lower three octets (as 1828 encoded) would make printable 7-bit ASCII values may be allocated 1829 only Specification Required. Sequential allocation of values is not 1830 required: specifications SHOULD include a specific request, and are 1831 encouraged to do early allocations. 1833 To be clear about the above category: four octet Element IDs always 1834 start with hex 0x10 to 0x1F, and that octet may be chosen so that the 1835 entire number has some desirable property, such as a specific CRC. 1836 The other three octets, when ALL having values between 0x21 (33, 1837 ASCII !) and 0x7e (126, ASCII ~), fall into this category. 1839 Other four octet Element IDs may be allocated by First Come First 1840 Served (see [RFC8126]). 1842 The numbers 0xFFFFFFF and 0x1000000 are RESERVED. 1844 Five octet Element IDs (values from 0x10000001 upwards) are reserved 1845 for Experimental use: they may be used by anyone at any time, but 1846 there is no coordination. 1848 ID Values found in this document are assigned as initial values as 1849 follows: 1851 +------------+-------------------------+----------------------------+ 1852 | ID | Element Name | Reference | 1853 +------------+-------------------------+----------------------------+ 1854 | 0x1A45DFA3 | EBML | Described in Section | 1855 | | | 13.2.1 | 1856 | 0x4286 | EBMLVersion | Described in Section | 1857 | | | 13.2.2 | 1858 | 0x42F7 | EBMLReadVersion | Described in Section | 1859 | | | 13.2.3 | 1860 | 0x42F2 | EBMLMaxIDLength | Described in Section | 1861 | | | 13.2.4 | 1862 | 0x42F3 | EBMLMaxSizeLength | Described in Section | 1863 | | | 13.2.5 | 1864 | 0x4282 | DocType | Described in Section | 1865 | | | 13.2.6 | 1866 | 0x4287 | DocTypeVersion | Described in Section | 1867 | | | 13.2.7 | 1868 | 0x4285 | DocTypeReadVersion | Described in Section | 1869 | | | 13.2.8 | 1870 | 0x4281 | DocTypeExtension | Described in Section | 1871 | | | 13.2.9 | 1872 | 0x4283 | DocTypeExtensionName | Described in Section | 1873 | | | 13.2.10 | 1874 | 0x4284 | DocTypeExtensionVersion | Described in Section | 1875 | | | 13.2.11 | 1876 | 0xBF | CRC-32 | Described in Section | 1877 | | | 13.3.1 | 1878 | 0xEC | Void | Described in Section | 1879 | | | 13.3.2 | 1880 +------------+-------------------------+----------------------------+ 1882 15.2. CELLAR EBML DocType Registry 1884 This document creates a new IANA Registry called "CELLAR EBML DocType 1885 Registry". 1887 DocType values are described in Section 13.1.2.1. DocTypes are ASCII 1888 strings, defined in Section 8.4, which label the official name of the 1889 "EBML Document Type". The strings may be allocated according to 1890 First Come First Served (see [RFC8126]). 1892 The use of ASCII corresponds to the types and code already in use, 1893 the value is not meant to be visible to the user. 1895 DocType string values of "matroska" and "webm" are reserved to the 1896 IETF for future use. These can be assigned via IESG Approval or RFC 1897 Required. 1899 16. References 1901 16.1. Normative References 1903 [IEEE.754.1985] 1904 Institute of Electrical and Electronics Engineers, 1905 "Standard for Binary Floating-Point Arithmetic", 1906 IEEE Standard 754, August 1985. 1908 [ISO.3309.1979] 1909 International Organization for Standardization, "Data 1910 communication - High-level data link control procedures - 1911 Frame structure", ISO Standard 3309, 1979. 1913 [ISO.9899.2011] 1914 International Organization for Standardization, 1915 "Programming languages - C", ISO Standard 9899, 2011. 1917 [ITU.V42.1994] 1918 International Telecommunications Union, "Error-correcting 1919 Procedures for DCEs Using Asynchronous-to-Synchronous 1920 Conversion", ITU-T Recommendation V.42, 1994. 1922 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1923 RFC 20, DOI 10.17487/RFC0020, October 1969, 1924 . 1926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1927 Requirement Levels", BCP 14, RFC 2119, 1928 DOI 10.17487/RFC2119, March 1997, 1929 . 1931 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1932 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1933 . 1935 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1936 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1937 2003, . 1939 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1940 Specifications: ABNF", STD 68, RFC 5234, 1941 DOI 10.17487/RFC5234, January 2008, 1942 . 1944 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1945 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1946 September 2009, . 1948 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1949 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1950 . 1952 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1953 Writing an IANA Considerations Section in RFCs", BCP 26, 1954 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1955 . 1957 [W3C.REC-xml-20081126] 1958 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1959 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1960 Edition)", World Wide Web Consortium Recommendation REC- 1961 xml-20081126, November 2008, 1962 . 1964 16.2. Informative References 1966 [W3C.REC-xmlschema-0-20010502] 1967 Fallside, D., "XML Schema Part 0: Primer", World Wide Web 1968 Consortium Recommendation REC-xmlschema-0-20010502, May 1969 2001, 1970 . 1972 Authors' Addresses 1974 Steve Lhomme 1976 Email: slhomme@matroska.org 1978 Dave Rice 1980 Email: dave@dericed.com 1982 Moritz Bunkus 1984 Email: moritz@bunkus.org