idnits 2.17.1 draft-ietf-cellar-ebml-09.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 24, 2019) is 1918 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) -- Looks like a reference, but probably isn't: '1' on line 1995 -- Looks like a reference, but probably isn't: '2' on line 1997 == Missing Reference: 'EBMLParentPath' is mentioned on line 1053, but not defined == Missing Reference: 'EBMLMinOccurrence' is mentioned on line 1064, but not defined == Missing Reference: 'EBMLMaxOccurrence' is mentioned on line 1064, but not defined == Missing Reference: 'PathMinOccurrence' is mentioned on line 1067, but not defined == Missing Reference: 'PathMaxOccurrence' is mentioned on line 1067, 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 (==), 5 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: July 28, 2019 6 M. Bunkus 7 January 24, 2019 9 Extensible Binary Meta Language 10 draft-ietf-cellar-ebml-09 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 July 28, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Element Data Size . . . . . . . . . . . . . . . . . . . . . . 11 68 8. EBML Element Types . . . . . . . . . . . . . . . . . . . . . 13 69 8.1. Signed Integer Element . . . . . . . . . . . . . . . . . 13 70 8.2. Unsigned Integer Element . . . . . . . . . . . . . . . . 14 71 8.3. Float Element . . . . . . . . . . . . . . . . . . . . . . 14 72 8.4. String Element . . . . . . . . . . . . . . . . . . . . . 14 73 8.5. UTF-8 Element . . . . . . . . . . . . . . . . . . . . . . 14 74 8.6. Date Element . . . . . . . . . . . . . . . . . . . . . . 15 75 8.7. Master Element . . . . . . . . . . . . . . . . . . . . . 15 76 8.8. Binary Element . . . . . . . . . . . . . . . . . . . . . 15 77 9. Terminating Elements . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . 17 82 10.1.3. Terminating Element Data . . . . . . . . . . . . . . 18 83 10.2. Considerations when Updating Elements with CRC . . . . . 18 84 11. EBML Document . . . . . . . . . . . . . . . . . . . . . . . . 18 85 11.1. EBML Header . . . . . . . . . . . . . . . . . . . . . . 18 86 11.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . . 19 87 12. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 13. Elements semantic . . . . . . . . . . . . . . . . . . . . . . 19 89 13.1. EBML Schema . . . . . . . . . . . . . . . . . . . . . . 19 90 13.1.1. EBML Schema Example . . . . . . . . . . . . . . . . 20 91 13.1.2. Element . . . . . . . . . . . . . . . . 21 92 13.1.3. Attributes . . . . . . . . . . . . . . 21 93 13.1.4. Element . . . . . . . . . . . . . . . . . 22 94 13.1.5. Attributes . . . . . . . . . . . . . . . . 22 95 13.1.6. Element . . . . . . . . . . . . . . 28 96 13.1.7. Attributes . . . . . . . . . . . . . 28 97 13.1.8. Element . . . . . . . . . . . . . . . 28 98 13.1.9. Element . . . . . . . . . . . . . . . . . . . 28 99 13.1.10. Attributes . . . . . . . . . . . . . . . . . 28 100 13.1.11. XML Schema for EBML Schema . . . . . . . . . . . . . 29 101 13.1.12. Identically Recurring Elements . . . . . . . . . . . 30 102 13.1.13. Textual expression of floats . . . . . . . . . . . . 30 103 13.1.14. Note on the use of default attributes to define 104 Mandatory EBML Elements . . . . . . . . . . . . . . 31 105 13.2. EBML Header Elements . . . . . . . . . . . . . . . . . . 32 106 13.2.1. EBML Element . . . . . . . . . . . . . . . . . . . . 32 107 13.2.2. EBMLVersion Element . . . . . . . . . . . . . . . . 32 108 13.2.3. EBMLReadVersion Element . . . . . . . . . . . . . . 33 109 13.2.4. EBMLMaxIDLength Element . . . . . . . . . . . . . . 33 110 13.2.5. EBMLMaxSizeLength Element . . . . . . . . . . . . . 34 111 13.2.6. DocType Element . . . . . . . . . . . . . . . . . . 34 112 13.2.7. DocTypeVersion Element . . . . . . . . . . . . . . . 35 113 13.2.8. DocTypeReadVersion Element . . . . . . . . . . . . . 35 114 13.2.9. DocTypeExtension Element . . . . . . . . . . . . . . 36 115 13.2.10. DocTypeExtensionName Element . . . . . . . . . . . . 36 116 13.2.11. DocTypeExtensionVersion Element . . . . . . . . . . 36 117 13.3. Global Elements . . . . . . . . . . . . . . . . . . . . 37 118 13.3.1. CRC-32 Element . . . . . . . . . . . . . . . . . . . 37 119 13.3.2. Void Element . . . . . . . . . . . . . . . . . . . . 38 120 14. Considerations for Reading EBML Data . . . . . . . . . . . . 38 121 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 122 15.1. CELLAR EBML Element ID Registry . . . . . . . . . . . . 38 123 15.2. CELLAR EBML DocType Registry . . . . . . . . . . . . . . 40 124 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 125 16.1. Normative References . . . . . . . . . . . . . . . . . . 41 126 16.2. Informative References . . . . . . . . . . . . . . . . . 42 127 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 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 using an "EBML Schema". "EBML" is used by the multimedia container 139 Matroska [1]. It MAY be used for use cases similar to those. The 140 applicability of "EBML" for other use cases is beyond the scope of 141 this document. 143 The definition of the "EBML" format recognizes the idea behind HTML 144 and XML as a good one: separate structure and semantics allowing the 145 same structural layer to be used with multiple, possibly widely 146 differing semantic layers. Except for the "EBML Header" and a few 147 "Global Elements" this specification does not define particular 148 "EBML" format semantics; however this specification is intended to 149 define how other "EBML"-based formats can be defined. 151 "EBML" uses a simple approach of building "Elements" upon three 152 pieces of data (tag, length, and value) as this approach is well 153 known, easy to parse, and allows selective data parsing. The "EBML" 154 structure additionally allows for hierarchical arrangement to support 155 complex structural formats in an efficient manner. 157 2. Notation and Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [2] [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 This document defines specific terms in order to define the format 166 and application of "EBML". Specific terms are defined below: 168 "EBML": Extensible Binary Meta Language 170 "EBML Document Type": A name provided by an "EBML Schema" to 171 designate a particular implementation of "EBML" for a data format 172 (e.g.: matroska and webm). 174 "EBML Schema": A standardized definition for the structure of an 175 "EBML Document Type". 177 "EBML Document": A datastream comprised of only two components, an 178 "EBML Header" and an "EBML Body". 180 "EBML Reader": A data parser that interprets the semantics of an 181 "EBML Document" and creates a way for programs to use "EBML". 183 "EBML Stream": A file that consists of one or more "EBML Documents" 184 that are concatenated together. 186 "EBML Header": A declaration that provides processing instructions 187 and identification of the "EBML Body". The "EBML Header" is 188 analogous to an XML Declaration [W3C.REC-xml-20081126] (see section 189 2.8 on Prolog and Document Type Declaration). 191 "EBML Body": All data of an "EBML Document" following the "EBML 192 Header". 194 "Variable Size Integer": A compact variable-length binary value which 195 defines its own length. 197 "VINT": Also known as "Variable Size Integer". 199 "EBML Element": A foundation block of data that contains three parts: 200 an "Element ID", an "Element Data Size", and "Element Data". 202 "Element ID": The "Element ID" is a binary value, encoded as a 203 "Variable Size Integer", used to uniquely identify a defined "EBML 204 Element" within a specific "EBML Schema". 206 "EBML Class": A representation of the octet length of an "Element 207 ID". 209 "Element Data Size": An expression, encoded as a "Variable Size 210 Integer", of the length in octets of "Element Data". 212 "VINTMAX": The maximum possible value that can be stored as "Element 213 Data Size". 215 "Unknown-Sized Element": An "Element" with an unknown "Element Data 216 Size". 218 "Element Data": The value(s) of the "EBML Element" which is 219 identified by its "Element ID" and "Element Data Size". The form of 220 the "Element Data" is defined by this document and the corresponding 221 "EBML Schema" of the Element's "EBML Document Type". 223 "Root Level": The starting level in the hierarchy of an "EBML 224 Document". 226 "Root Element": A mandatory, non-repeating "EBML Element" which 227 occurs at the top level of the path hierarchy within an "EBML Body" 228 and contains all other "EBML Elements" of the "EBML Body", excepting 229 optional "Void Elements". 231 "Top-Level Element": An "EBML Element" defined to only occur as a 232 "Child Element" of the "Root Element". 234 "Master Element": The "Master Element" contains zero, one, or many 235 other "EBML Elements". 237 "Child Element": A "Child Element" is a relative term to describe the 238 "EBML Elements" immediately contained within a "Master Element". 240 "Parent Element": A relative term to describe the "Master Element" 241 which contains a specified element. For any specified "EBML Element" 242 that is not at "Root Level", the "Parent Element" refers to the 243 "Master Element" in which that "EBML Element" is contained. 245 "Descendant Element": A relative term to describe any "EBML Elements" 246 contained within a "Master Element", including any of the "Child 247 Elements" of its "Child Elements", and so on. 249 "Void Element": A "Void Element" is an "Element" used to overwrite 250 damaged data or reserve space within a "Master Element" for later 251 use. 253 "Element Name": The official human-readable name of the "EBML 254 Element". 256 "Element Path": The hierarchy of "Parent Element" where the "EBML 257 Element" is expected to be found in the "EBML Body". 259 "Empty Element": An "EBML Element" that has an "Element Data Size" 260 with all "VINT_DATA" bits set to zero, which indicates that the 261 "Element Data" of the "Element" is zero octets in length. 263 3. Security Considerations 265 "EBML" itself does not offer any kind of security and does not 266 provide confidentiality. "EBML" does not provide any kind of 267 authorization. "EBML" only offers marginally useful and effective 268 data integrity options, such as CRC elements. 270 Even if the semantic layer offers any kind of encryption, "EBML" 271 itself could leak information at both the semantic layer (as declared 272 via the "DocType Element") and within the "EBML" structure (the 273 presence of "EBML Elements" can be derived even with an unknown 274 semantic layer using a heuristic approach; not without errors, of 275 course, but with a certain degree of confidence). 277 An "EBML Document" that has the following issues may still be handled 278 by the "EBML Reader" and the data accepted as such: 280 o Invalid "Element IDs" that are longer than the limit stated in the 281 "EBMLMaxIDLength Element" of the "EBML Header". 283 o Invalid "Element IDs" that are not encoded in the shortest- 284 possible way. 286 o Invalid "Element IDs" comprised of reserved values. 288 o Invalid "Element Data Size" values that are longer than the limit 289 stated in the "EBMLMaxSizeLength Element" of the "EBML Header". 291 o Usage of "0x00" octets in "EBML Elements" with a string type. 293 An "EBML Reader" may discard some or all data if the following errors 294 are found in the "EBML Document": 296 o Invalid "Element Data Size" values (e.g. extending the length of 297 the "EBML Element" beyond the scope of the "Parent Element"; 298 possibly triggering access-out-of-bounds issues). 300 o Very high lengths in order to force out-of-memory situations 301 resulting in a denial of service, access-out-of-bounds issues etc. 303 o Missing "EBML Elements" that are mandatory and have no declared 304 default value. 306 o Usage of invalid UTF-8 encoding in "EBML Elements" of UTF-8 type 307 (e.g. in order to trigger access-out-of-bounds or buffer overflow 308 issues). 310 o Usage of invalid data in "EBML Elements" with a date type. 312 Side channel attacks could exploit: 314 o The semantic equivalence of the same string stored in a "String 315 Element" or "UTF-8 Element" with and without zero-bit padding. 317 o The semantic equivalence of "VINT_DATA" within "Element Data Size" 318 with two different lengths due to left-padding zero bits. 320 o Data contained within a "Master Element" which is not itself part 321 of an "EBML Element". 323 o Extraneous copies of "Identically Recurring Element". 325 o Copies of "Identically Recurring Element" within a "Parent 326 Element" that contain invalid "CRC-32 Elements". 328 o Use of "Void Elements". 330 An "EBML Reader" MAY use the data if it considers it doesn't create 331 any security issue. 333 4. Structure 335 "EBML" uses a system of "Elements" to compose an "EBML Document". 336 "EBML Elements" incorporate three parts: an "Element ID", an "Element 337 Data Size", and "Element Data". The "Element Data", which is 338 described by the "Element ID", includes either binary data, one or 339 more other "EBML Elements", or both. 341 5. Variable Size Integer 343 The "Element ID" and "Element Data Size" are both encoded as a 344 "Variable Size Integer". The "Variable Size Integer" is composed of 345 a "VINT_WIDTH", "VINT_MARKER", and "VINT_DATA", in that order. 346 "Variable Size Integers" MUST left-pad the "VINT_DATA" value with 347 zero bits so that the whole "Variable Size Integer" is octet-aligned. 348 "Variable Size Integer" will be referred to as "VINT" for shorthand. 350 5.1. VINT_WIDTH 352 Each "Variable Size Integer" begins with a "VINT_WIDTH" which 353 consists of zero or many zero-value bits. The count of consecutive 354 zero-values of the "VINT_WIDTH" plus one equals the length in octets 355 of the "Variable Size Integer". For example, a "Variable Size 356 Integer" that starts with a "VINT_WIDTH" which contains zero 357 consecutive zero-value bits is one octet in length and a "Variable 358 Size Integer" that starts with one consecutive zero-value bit is two 359 octets in length. The "VINT_WIDTH" MUST only contain zero-value bits 360 or be empty. 362 Within the "EBML Header" the "VINT_WIDTH" MUST NOT exceed three bits 363 in length (meaning that the "Variable Size Integer" MUST NOT exceed 364 four octets in length). Within the "EBML Body", when a "VINT" is 365 used to express an "Element ID", the maximum length allowed for the 366 "VINT_WIDTH" is one less than the value set in the "EBMLMaxIDLength 367 Element". Within the "EBML Body", when a "VINT" is used to express 368 an "Element Data Size", the maximum length allowed for the 369 "VINT_WIDTH" is one less than the value set in the "EBMLMaxSizeLength 370 Element". 372 5.2. VINT_MARKER 374 The "VINT_MARKER" serves as a separator between the "VINT_WIDTH" and 375 "VINT_DATA". Each "Variable Size Integer" MUST contain exactly one 376 "VINT_MARKER". The "VINT_MARKER" is one bit in length and contain a 377 bit with a value of one. The first bit with a value of one within 378 the "Variable Size Integer" is the "VINT_MARKER". 380 5.3. VINT_DATA 382 The "VINT_DATA" portion of the "Variable Size Integer" includes all 383 data that follows (but not including) the "VINT_MARKER" until end of 384 the "Variable Size Integer" whose length is derived from the 385 "VINT_WIDTH". The bits required for the "VINT_WIDTH" and the 386 "VINT_MARKER" use one out of every eight bits of the total length of 387 the "Variable Size Integer". Thus a "Variable Size Integer" of 1 388 octet length supplies 7 bits for "VINT_DATA", a 2 octet length 389 supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21 390 bits for "VINT_DATA". If the number of bits required for "VINT_DATA" 391 are less than the bit size of "VINT_DATA", then "VINT_DATA" MUST be 392 zero-padded to the left to a size that fits. The "VINT_DATA" value 393 MUST be expressed as a big-endian unsigned integer. 395 5.4. VINT Examples 397 This table shows examples of "Variable Size Integers" with lengths 398 from 1 to 5 octets. The Size column refers to the size of the 399 "VINT_DATA" in bits. The Representation column depicts a binary 400 expression of "Variable Size Integers" where "VINT_WIDTH" is depicted 401 by '0', the "VINT_MARKER" as '1', and the "VINT_DATA" as 'x'. 403 +-------------+------+----------------------------------------------+ 404 | Octet | Size | Representation | 405 | Length | | | 406 +-------------+------+----------------------------------------------+ 407 | 1 | 2^7 | 1xxx xxxx | 408 | 2 | 2^14 | 01xx xxxx xxxx xxxx | 409 | 3 | 2^21 | 001x xxxx xxxx xxxx xxxx xxxx | 410 | 4 | 2^28 | 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 411 | 5 | 2^35 | 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | 412 | | | xxxx | 413 +-------------+------+----------------------------------------------+ 415 Data encoded as a "Variable Size Integer" MAY be rendered at octet 416 lengths larger than needed to store the data in order to facilitate 417 overwriting it at a later date, e.g. when its final size isn't known 418 in advance. In this table a binary value of "0b10" is shown encoded 419 as different "Variable Size Integers" with lengths from one octet to 420 four octet. All four encoded examples have identical semantic 421 meaning though the "VINT_WIDTH" and the padding of the "VINT_DATA" 422 vary. 424 +--------------+--------------+-------------------------------------+ 425 | Binary Value | Octet Length | As Represented in Variable Size | 426 | | | Integer | 427 +--------------+--------------+-------------------------------------+ 428 | 10 | 1 | 1000 0010 | 429 | 10 | 2 | 0100 0000 0000 0010 | 430 | 10 | 3 | 0010 0000 0000 0000 0000 0010 | 431 | 10 | 4 | 0001 0000 0000 0000 0000 0000 0000 | 432 | | | 0010 | 433 +--------------+--------------+-------------------------------------+ 435 6. Element ID 437 The "Element ID" is encoded as a "Variable Size Integer". By 438 default, "Element IDs" are encoded in lengths from one octet to four 439 octets, although "Element IDs" of greater lengths are used if the 440 octet length of the longest "Element ID" of the "EBML Document" is 441 declared in the "EBMLMaxIDLength Element" of the "EBML Header" (see 442 Section 13.2.4). The "VINT_DATA" component of the "Element ID" MUST 443 NOT be either defined or written as either all zero values or all one 444 values. Any "Element ID" with the "VINT_DATA" component set as all 445 zero values or all one values MUST be ignored. The "VINT_DATA" 446 component of the "Element ID" MUST be encoded at the shortest valid 447 length. For example, an "Element ID" with binary encoding of "1011 448 1111" is valid, whereas an "Element ID" with binary encoding of "0100 449 0000 0011 1111" stores a semantically equal "VINT_DATA" but is 450 invalid because a shorter "VINT" encoding is possible. Additionally, 451 an "Element ID" with binary encoding of "1111 1111" is invalid since 452 the "VINT_DATA" section is set to all one values, whereas an "Element 453 ID" with binary encoding of "0100 0000 0111 1111" stores a 454 semantically equal "VINT_DATA" and is the shortest possible "VINT" 455 encoding. 457 The following table details these specific examples further: 459 +------------+-------------+----------------+-----------------------+ 460 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status | 461 +------------+-------------+----------------+-----------------------+ 462 | | 1 | 0000000 | Invalid: "VINT_DATA" | 463 | | | | MUST NOT be set to | 464 | | | | all 0 | 465 | 0 | 1 | 00000000000000 | Invalid: "VINT_DATA" | 466 | | | | MUST NOT be set to | 467 | | | | all 0 | 468 | | 1 | 0000001 | Valid | 469 | 0 | 1 | 00000000000001 | Invalid: A shorter | 470 | | | | "VINT_DATA" encoding | 471 | | | | is available. | 472 | | 1 | 0111111 | Valid | 473 | 0 | 1 | 00000000111111 | Invalid: A shorter | 474 | | | | "VINT_DATA" encoding | 475 | | | | is available. | 476 | | 1 | 1111111 | Invalid: "VINT_DATA" | 477 | | | | MUST NOT be set to | 478 | | | | all 1 | 479 | 0 | 1 | 00000001111111 | Valid | 480 +------------+-------------+----------------+-----------------------+ 482 The octet length of an "Element ID" determines its "EBML Class". 484 +------------+--------------+--------------------------------+ 485 | EBML Class | Octet Length | Number of Possible Element IDs | 486 +------------+--------------+--------------------------------+ 487 | Class A | 1 | 2^7 - 2 = 126 | 488 | Class B | 2 | 2^14 - 2^7 - 1 = 16,255 | 489 | Class C | 3 | 2^21 - 2^14 - 1 = 2,080,767 | 490 | Class D | 4 | 2^28 - 2^21 - 1 = 266,338,303 | 491 +------------+--------------+--------------------------------+ 493 7. Element Data Size 495 The "Element Data Size" expresses the length in octets of "Element 496 Data". The "Element Data Size" itself is encoded as a "Variable Size 497 Integer". By default, "Element Data Sizes" can be encoded in lengths 498 from one octet to eight octets, although "Element Data Sizes" of 499 greater lengths MAY be used if the octet length of the longest 500 "Element Data Size" of the "EBML Document" is declared in the 501 "EBMLMaxSizeLength Element" of the "EBML Header" (see 502 Section 13.2.5). Unlike the "VINT_DATA" of the "Element ID", the 503 "VINT_DATA" component of the "Element Data Size" is not mandated to 504 be encoded at the shortest valid length. For example, an "Element 505 Data Size" with binary encoding of "1011 1111" or a binary encoding 506 of "0100 0000 0011 1111" are both valid "Element Data Sizes" and both 507 store a semantically equal value (both "0b00000000111111" and 508 "0b0111111", the "VINT_DATA" sections of the examples, represent the 509 integer 63). 511 Although an "Element ID" with all "VINT_DATA" bits set to zero is 512 invalid, an "Element Data Size" with all "VINT_DATA" bits set to zero 513 is allowed for "EBML Element Types" which do not mandate a non-zero 514 length (see Section 8). An "Element Data Size" with all "VINT_DATA" 515 bits set to zero indicates that the "Element Data" is zero octets in 516 length. Such an "EBML Element" is referred to as an "Empty Element". 517 If an "Empty Element" has a "default" value declared then the "EBML 518 Reader" MUST interpret the value of the "Empty Element" as the 519 "default" value. If an "Empty Element" has no "default" value 520 declared then the "EBML Reader" MUST interpret the value of the 521 "Empty Element" as defined as part of the definition of the 522 corresponding "EBML Element Type" associated with the "Element ID". 524 An "Element Data Size" with all "VINT_DATA" bits set to one is 525 reserved as an indicator that the size of the "EBML Element" is 526 unknown. The only reserved value for the "VINT_DATA" of "Element 527 Data Size" is all bits set to one. An "EBML Element" with an unknown 528 "Element Data Size" is referred to as an "Unknown-Sized Element". A 529 "Master Element" MAY be an "Unknown-Sized Element"; however an "EBML 530 Element" that is not a "Master Element" MUST NOT be an "Unknown-Sized 531 Element". "Master Elements" MUST NOT use an unknown size unless the 532 "unknownsizeallowed" attribute of their "EBML Schema" is set to true 533 (see Section 13.1.5.10). The use of "Unknown-Sized Elements" allows 534 for an "EBML Element" to be written and read before the size of the 535 "EBML Element" is known. "Unknown-Sized Element" MUST NOT be used or 536 defined unnecessarily; however if the "Element Data Size" is not 537 known before the "Element Data" is written, such as in some cases of 538 data streaming, then "Unknown-Sized Elements" MAY be used. The end 539 of an "Unknown-Sized Element" is determined by whichever comes first: 540 the end of the file or the beginning of the next "EBML Element", 541 defined by this document or the corresponding "EBML Schema", that is 542 not independently valid as "Descendant Element" of the "Unknown-Sized 543 Element". 545 For "Element Data Sizes" encoded at octet lengths from one to eight, 546 this table depicts the range of possible values that can be encoded 547 as an "Element Data Size". An "Element Data Size" with an octet 548 length of 8 is able to express a size of 2^56-2 or 549 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum 550 possible value that can be stored as "Element Data Size" is referred 551 to as "VINTMAX". 553 +--------------+----------------------+ 554 | Octet Length | Possible Value Range | 555 +--------------+----------------------+ 556 | 1 | 0 to 2^7-2 | 557 | 2 | 0 to 2^14-2 | 558 | 3 | 0 to 2^21-2 | 559 | 4 | 0 to 2^28-2 | 560 | 5 | 0 to 2^35-2 | 561 | 6 | 0 to 2^42-2 | 562 | 7 | 0 to 2^49-2 | 563 | 8 | 0 to 2^56-2 | 564 +--------------+----------------------+ 566 If the length of "Element Data" equals "2^(n*7)-1" then the octet 567 length of the "Element Data Size" MUST be at least "n+1". This rule 568 prevents an "Element Data Size" from being expressed as a reserved 569 value. The following table clarifies this rule by showing a valid 570 and invalid expression of an "Element Data Size" with a "VINT_DATA" 571 of 127 (which is equal to 2^(1_7)-1) and 16,383 (which is equal to 572 2^(2_7)-1). 574 +------------+-------------+-----------------------+----------------+ 575 | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element Data | 576 | | | | Size Status | 577 +------------+-------------+-----------------------+----------------+ 578 | | 1 | 1111111 | Reserved | 579 | | | | (meaning | 580 | | | | Unknown) | 581 | 0 | 1 | 00000001111111 | Valid (meaning | 582 | | | | 127 octets) | 583 | 00 | 1 | 000000000000001111111 | Valid (meaning | 584 | | | | 127 octets) | 585 | 0 | 1 | 11111111111111 | Reserved | 586 | | | | (meaning | 587 | | | | Unknown) | 588 | 00 | 1 | 000000011111111111111 | Valid (16,383 | 589 | | | | octets) | 590 +------------+-------------+-----------------------+----------------+ 592 8. EBML Element Types 594 "EBML Elements" are defined by an "EBML Schema" which MUST declare 595 one of the following "EBML Element Types" for each "EBML Element". 596 An "EBML Element Type" defines a concept of storing data within an 597 "EBML Element" that describes such characteristics as length, 598 endianness, and definition. 600 "EBML Elements" which are defined as a "Signed Integer Element", 601 "Unsigned Integer Element", "Float Element", or "Date Element" use 602 big endian storage. 604 8.1. Signed Integer Element 606 A "Signed Integer Element" MUST declare a length from zero to eight 607 octets. If the "EBML Element" is not defined to have a "default" 608 value, then a "Signed Integer Element" with a zero-octet length 609 represents an integer value of zero. 611 A "Signed Integer Element" stores an integer (meaning that it can be 612 written without a fractional component) which could be negative, 613 positive, or zero. Signed Integers are stored with two's complement 614 notation with the leftmost bit being the sign bit. Because "EBML" 615 limits Signed Integers to 8 octets in length a "Signed Integer 616 Element" stores a number from -9,223,372,036,854,775,808 to 617 +9,223,372,036,854,775,807. 619 8.2. Unsigned Integer Element 621 An "Unsigned Integer Element" MUST declare a length from zero to 622 eight octets. If the "EBML Element" is not defined to have a 623 "default" value, then an "Unsigned Integer Element" with a zero-octet 624 length represents an integer value of zero. 626 An "Unsigned Integer Element" stores an integer (meaning that it can 627 be written without a fractional component) which could be positive or 628 zero. Because "EBML" limits Unsigned Integers to 8 octets in length 629 an "Unsigned Integer Element" stores a number from 0 to 630 18,446,744,073,709,551,615. 632 8.3. Float Element 634 A "Float Element" MUST declare a length of either zero octets (0 635 bit), four octets (32 bit) or eight octets (64 bit). If the "EBML 636 Element" is not defined to have a "default" value, then a "Float 637 Element" with a zero-octet length represents a numerical value of 638 zero. 640 A "Float Element" stores a floating-point number as defined in 641 [IEEE.754.1985]. 643 8.4. String Element 645 A "String Element" MUST declare a length in octets from zero to 646 "VINTMAX". If the "EBML Element" is not defined to have a "default" 647 value, then a "String Element" with a zero-octet length represents an 648 empty string. 650 A "String Element" MUST either be empty (zero-length) or contain 651 printable ASCII characters [RFC0020] in the range of "0x20" to 652 "0x7E", with an exception made for termination (see Section 9). 654 8.5. UTF-8 Element 656 A "UTF-8 Element" MUST declare a length in octets from zero to 657 "VINTMAX". If the "EBML Element" is not defined to have a "default" 658 value, then a "UTF-8 Element" with a zero-octet length represents an 659 empty string. 661 A "UTF-8 Element" contains only a valid Unicode string as defined in 662 [RFC3629], with an exception made for termination (see Section 9). 664 8.6. Date Element 666 A "Date Element" MUST declare a length of either zero octets or eight 667 octets. If the "EBML Element" is not defined to have a "default" 668 value, then a "Date Element" with a zero-octet length represents a 669 timestamp of 2001-01-01T00:00:00.000000000 UTC [RFC3339]. 671 The "Date Element" stores an integer in the same format as the 672 "Signed Integer Element" that expresses a point in time referenced in 673 nanoseconds from the precise beginning of the third millennium of the 674 Gregorian Calendar in Coordinated Universal Time (also known as 675 2001-01-01T00:00:00.000000000 UTC). This provides a possible 676 expression of time from 1708-09-11T00:12:44.854775808 UTC to 677 2293-04-11T11:47:16.854775807 UTC. 679 8.7. Master Element 681 A "Master Element" MUST declare a length in octets from zero to 682 "VINTMAX". The "Master Element" MAY also use an unknown length. See 683 Section 7 for rules that apply to elements of unknown length. 685 The "Master Element" contains zero, one, or many other elements. 686 "EBML Elements" contained within a "Master Element" MUST have the 687 "EBMLParentPath" of their "Element Path" equals to the 688 "EBMLReferencePath" of the "Master Element" "Element Path" (see 689 Section 13.1.5.2). "Element Data" stored within "Master Elements" 690 SHOULD only consist of "EBML Elements" and SHOULD NOT contain any 691 data that is not part of an "EBML Element". When "EBML" is used in 692 transmission or streaming, data that is not part of an "EBML Element" 693 is permitted to be present within a "Master Element" if 694 "unknownsizeallowed" is enabled within the definition for that 695 "Master Element". In this case, the "EBML Reader" should skip data 696 until a valid "Element ID" of the same "EBMLParentPath" or the next 697 upper level "Element Path" of the "Master Element" is found. The 698 "EBML Schema" identifies what "Element IDs" are valid within the 699 "Master Elements" for that version of the "EBML Document Type". Any 700 data contained within a "Master Element" that is not part of a "Child 701 Element" MUST be ignored. 703 8.8. Binary Element 705 A "Binary Element" MUST declare a length in octets from zero to 706 "VINTMAX". 708 The contents of a "Binary Element" should not be interpreted by the 709 "EBML Reader". 711 9. Terminating Elements 713 "Null Octets", which are octets with all bits set to zero, MAY follow 714 the value of a "String Element" or "UTF-8 Element" to serve as a 715 terminator. An "EBML Writer" MAY terminate a "String Element" or 716 "UTF-8 Element" with "Null Octets" in order to overwrite a stored 717 value with a new value of lesser length while maintaining the same 718 "Element Data Size" (this can prevent the need to rewrite large 719 portions of an "EBML Document"); otherwise the use of "Null Octets" 720 within a "String Element" or "UTF-8 Element" is NOT RECOMMENDED. An 721 "EBML Reader" MUST consider the value of the "String Element" or 722 "UTF-8 Element" to be terminated upon the first read "Null Octet" and 723 MUST ignore any data following the first "Null Octet" within that 724 "Element". A string value and a copy of that string value terminated 725 by one or more "Null Octets" are semantically equal. 727 The following table shows examples of semantics and validation for 728 the use of "Null Octets". Values to represent "Stored Values" and 729 the "Semantic Meaning" as represented as hexadecimal values. 731 +---------------------+---------------------+ 732 | Stored Value | Semantic Meaning | 733 +---------------------+---------------------+ 734 | 0x65 0x62 0x6d 0x6c | 0x65 0x62 0x6d 0x6c | 735 | 0x65 0x62 0x00 0x6c | 0x65 0x62 | 736 | 0x65 0x62 0x00 0x00 | 0x65 0x62 | 737 | 0x65 0x62 | 0x65 0x62 | 738 +---------------------+---------------------+ 740 10. Guidelines for Updating Elements 742 An EBML Document can be updated without requiring that the entire 743 EBML Document be rewritten. These recommendations describe 744 strategies to change the "Element Data" of a written "EBML Element" 745 with minimal disruption to the rest of the "EBML Document". 747 10.1. Reducing a Element Data in Size 749 There are three methods to reduce the size of "Element Data" of a 750 written "EBML Element". 752 10.1.1. Adding a Void Element 754 When an "EBML Element" is changed to reduce its total length by more 755 than one octet, an "EBML Writer" SHOULD fill the freed space with a 756 "Void Element". 758 10.1.2. Extending the Element Data Size 760 The same value for "Element Data Size" MAY be written in variable 761 lengths, so for minor reductions in octet length the "Element Data 762 Size" MAY be written to a longer octet length to fill the freed 763 space. 765 For example, the first row of the following table depicts a "String 766 Element" that stores an "Element ID" (3 octets), "Element Data Size" 767 (1 octet), and "Element Data" (4 octets). If the "Element Data" is 768 changed to reduce the length by one octet and if the current length 769 of the "Element Data Size" is less than its maximum permitted length, 770 then the "Element Data Size" of that "Element" MAY be rewritten to 771 increase its length by one octet. Thus before and after the change 772 the "EBML Element" maintains the same length of 8 octets and data 773 around the "Element" does not need to be moved. 775 +-------------+------------+-------------------+--------------+ 776 | Status | Element ID | Element Data Size | Element Data | 777 +-------------+------------+-------------------+--------------+ 778 | Before edit | 0x3B4040 | 0x84 | 0x65626d6c | 779 | After edit | 0x3B4040 | 0x4003 | 0x6d6b76 | 780 +-------------+------------+-------------------+--------------+ 782 This method is RECOMMENDED when the "Element Data" is reduced by a 783 single octet; for reductions by two or more octets it is RECOMMENDED 784 to fill the freed space with a "Void Element". 786 Note that if the "Element Data" length needs to be rewritten as 787 shortened by one octet and the "Element Data Size" could be rewritten 788 as a shorter "VINT" then it is RECOMMENDED to rewrite the "Element 789 Data Size" as one octet shorter, shorten the "Element Data" by one 790 octet, and follow that "Element" with a "Void Element". For example, 791 the following table depicts a "String Element" that stores an 792 "Element ID" (3 octets), "Element Data Size" (2 octets, but could be 793 rewritten in one octet), and "Element Data" (3 octets). If the 794 "Element Data" is to be rewritten to a two octet length, then another 795 octet can be taken from "Element Data Size" so that there is enough 796 space to add a two octet "Void Element". 798 +--------+------------+-----------------+-------------+-------------+ 799 | Status | Element ID | Element Data | Element | Void | 800 | | | Size | Data | Element | 801 +--------+------------+-----------------+-------------+-------------+ 802 | Before | 0x3B4040 | 0x4003 | 0x6d6b76 | | 803 | After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 | 804 +--------+------------+-----------------+-------------+-------------+ 806 10.1.3. Terminating Element Data 808 For "String Elements" and "UTF-8 Elements" the length of "Element 809 Data" MAY be reduced by adding "Null Octets" to terminate the 810 "Element Data" (see Section 9). 812 In the following table, a four octet long "Element Data" is changed 813 to a three octet long value followed by a "Null Octet"; the "Element 814 Data Size" includes any "Null Octets" used to terminate "Element 815 Data" so remains unchanged. 817 +-------------+------------+-------------------+--------------+ 818 | Status | Element ID | Element Data Size | Element Data | 819 +-------------+------------+-------------------+--------------+ 820 | Before edit | 0x3B4040 | 0x84 | 0x65626d6c | 821 | After edit | 0x3B4040 | 0x84 | 0x6d6b7600 | 822 +-------------+------------+-------------------+--------------+ 824 Note that this method is NOT RECOMMENDED. For reductions of one 825 octet, the method for "Extending the Element Data Size" SHOULD be 826 used. For reduction by more than one octet, the method for "Adding a 827 Void Element" SHOULD be used. 829 10.2. Considerations when Updating Elements with CRC 831 If the "Element" to be changed is a "Descendant Element" of any 832 "Master Element" that contains an "CRC-32 Element" then the "CRC-32 833 Element" MUST be verified before permitting the change. Additionally 834 the "CRC-32 Element" value MUST be subsequently updated to reflect 835 the changed data. 837 11. EBML Document 839 An "EBML Document" is comprised of only two components, an "EBML 840 Header" and an "EBML Body". An "EBML Document" MUST start with an 841 "EBML Header" that declares significant characteristics of the entire 842 "EBML Body". An "EBML Document" consists of "EBML Elements" and MUST 843 NOT contain any data that is not part of an "EBML Element". 845 11.1. EBML Header 847 The "EBML Header" is a declaration that provides processing 848 instructions and identification of the "EBML Body". The "EBML 849 Header" of an "EBML Document" is analogous to the XML Declaration of 850 an XML Document. 852 The "EBML Header" documents the "EBML Schema" (also known as the 853 "EBML DocType") that is used to semantically interpret the structure 854 and meaning of the "EBML Document". Additionally the "EBML Header" 855 documents the versions of both "EBML" and the "EBML Schema" that were 856 used to write the "EBML Document" and the versions required to read 857 the "EBML Document". 859 The "EBML Header" MUST contain a single "Master Element" with an 860 "Element Name" of "EBML" and "Element ID" of "0x1A45DFA3" (see 861 Section 13.2.1) and any number of additional "EBML Elements" within 862 it. The "EBML Header" of an "EBML Document" that uses an 863 "EBMLVersion" of "1" MUST only contain "EBML Elements" that are 864 defined as part of this document. 866 "EBML Elements" within the "EBML Header" MUST NOT use any "Element 867 ID" with a length greater than 4 octets. All "EBML Elements" within 868 the "EBML Header" MUST NOT use any "Element Data Size" with a length 869 greater than 4 octets. 871 11.2. EBML Body 873 All data of an "EBML Document" following the "EBML Header" is the 874 "EBML Body". The end of the "EBML Body", as well as the end of the 875 "EBML Document" that contains the "EBML Body", is reached at 876 whichever comes first: the beginning of a new "EBML Header" at the 877 "Root Level" or the end of the file. The "EBML Body" MUST consist 878 only of "EBML Elements" and MUST NOT contain any data that is not 879 part of an "EBML Element". This document defines precisely what 880 "EBML Elements" are to be used within the "EBML Header", but does not 881 name or define what "EBML Elements" are to be used within the "EBML 882 Body". The definition of what "EBML Elements" are to be used within 883 the "EBML Body" is defined by an "EBML Schema". 885 12. EBML Stream 887 An "EBML Stream" is a file that consists of one or more "EBML 888 Documents" that are concatenated together. An occurrence of a "EBML 889 Header" at the "Root Level" marks the beginning of an "EBML 890 Document". 892 13. Elements semantic 894 13.1. EBML Schema 896 An "EBML Schema" is a well-formed XML Document that defines the 897 properties, arrangement, and usage of "EBML Elements" that compose a 898 specific "EBML Document Type". The relationship of an "EBML Schema" 899 to an "EBML Document" is analogous to the relationship of an XML 900 Schema [W3C.REC-xmlschema-0-20010502] to an XML Document 901 [W3C.REC-xml-20081126]. An "EBML Schema" MUST be clearly associated 902 with one or more "EBML Document Types". An "EBML Document Type" is 903 identified by a string stored within the "EBML Header" in the 904 "DocType Element"; for example "matroska" or "webm" (see 905 Section 13.2.6). The "DocType" value for an "EBML Document Type" 906 SHOULD be unique and persistent. 908 An "EBML Schema" MUST declare exactly one "EBML Element" at "Root 909 Level" (referred to as the "Root Element") that occurs exactly once 910 within an "EBML Document". The "Void Element" MAY also occur at 911 "Root Level" but is not a "Root Element" (see Section 13.3.2). 913 The "EBML Schema" MUST document all Elements of the "EBML Body". The 914 "EBML Schema" does not document "Global Elements" that are defined by 915 this document (namely the "Void Element" and the "CRC-32 Element"). 917 An "EBML Schema" MAY constrain the use of "EBML Header Elements" (see 918 Section 13.2) by adding or constraining that Element's "range" 919 attribute. For example, an "EBML Schema" MAY constrain the 920 "EBMLMaxSizeLength" to a maximum value of "8" or MAY constrain the 921 "EBMLVersion" to only support a value of "1". If an "EBML Schema" 922 adopts the "EBML Header Element" as-is, then it is not required to 923 document that Element within the "EBML Schema". If an "EBML Schema" 924 constrains the range of an "EBML Header Element", then that "Element" 925 MUST be documented within an "" node of the "EBML Schema". 926 This document provides an example of an "EBML Schema", see 927 Section 13.1.1. 929 13.1.1. EBML Schema Example 931 932 934 935 938 941 942 943 Container of data and 944 attributes representing one or many files. 945 946 948 949 An attached file. 951 952 953 956 957 Filename of the attached file. 958 959 960 963 964 MIME type of the file. 965 966 967 970 971 Modification timestamp of the file. 972 973 974 976 977 The data of the file. 978 979 980 982 13.1.2. Element 984 As an XML Document, the "EBML Schema" MUST use "" as the 985 top level element. The "" element MAY contain 986 "" sub-elements. 988 13.1.3. Attributes 990 Within an "EBML Schema" the "" element uses the following 991 attributes: 993 13.1.3.1. docType 995 The "docType" lists the official name of the "EBML Document Type" 996 that is defined by the "EBML Schema"; for example, "". 999 The "docType" attribute is REQUIRED within the "" 1000 Element. 1002 13.1.3.2. version 1004 The "version" lists an non-negative integer that specifies the 1005 version of the docType documented by the "EBML Schema". Unlike XML 1006 Schemas, an "EBML Schema" documents all versions of a docType's 1007 definition rather than using separate "EBML Schemas" for each version 1008 of a "docType". "EBML Elements" may be introduced and deprecated by 1009 using the "minver" and "maxver" attributes of "". 1011 The "version" attribute is REQUIRED within the "" 1012 Element. 1014 13.1.4. Element 1016 Each "" defines one "EBML Element" through the use of 1017 several attributes that are defined in Section 13.1.3. "EBML 1018 Schemas" MAY contain additional attributes to extend the semantics 1019 but MUST NOT conflict with the definitions of the "" 1020 attributes defined within this document. 1022 The "" nodes contain a description of the meaning and use of 1023 the "EBML Element" stored within one or more "" sub- 1024 elements and zero or one "" sub-element. All 1025 "" nodes MUST be sub-elements of the "". 1027 13.1.5. Attributes 1029 Within an "EBML Schema" the "" uses the following attributes 1030 to define an "EBML Element": 1032 13.1.5.1. name 1034 The "name" provides the official human-readable name of the "EBML 1035 Element". The value of the name MUST be in the form of characters 1036 "A" to "Z", "a" to "z", "0" to "9", "-" and ".". 1038 The "name" attribute is REQUIRED. 1040 13.1.5.2. path 1042 The path defines the allowed storage locations of the "EBML Element" 1043 within an "EBML Document". This path MUST be defined with the full 1044 hierarchy of "EBML Elements" separated with a "/". The top "EBML 1045 Element" in the path hierarchy being the first in the value. The 1046 syntax of the "path" attribute is defined using this Augmented 1047 Backus-Naur Form (ABNF) [RFC5234] with the case sensitive update 1048 [RFC7405] notation: 1050 The "path" attribute is REQUIRED. 1052 EBMLFullPath = EBMLElementOccurrence "(" EBMLReferencePath ")" 1053 EBMLReferencePath = [EBMLParentPath] EBMLElementPath 1054 EBMLParentPath = EBMLFixedParent EBMLLastParent 1055 EBMLFixedParent = *(EBMLPathAtom) 1056 EBMLElementPath = EBMLPathAtom / EBMLPathAtomRecursive 1057 EBMLPathAtom = PathDelimiter EBMLAtomName 1058 EBMLPathAtomRecursive = "(1*(" EBMLPathAtom "))" 1059 EBMLLastParent = EBMLPathAtom / EBMLVariableParent 1060 EBMLVariableParent = "(" VariableParentOccurrence "\)" 1061 EBMLAtomName = 1*(EBMLNameChar) 1062 EBMLNameChar = ALPHA / DIGIT / "-" / "." 1063 PathDelimiter = "\" 1064 EBMLElementOccurrence = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence] 1065 EBMLMinOccurrence = 1*DIGIT 1066 EBMLMaxOccurrence = 1*DIGIT 1067 VariableParentOccurrence = [PathMinOccurrence] "*" [PathMaxOccurrence] 1068 PathMinOccurrence = 1*DIGIT 1069 PathMaxOccurrence = 1*DIGIT 1071 The ""*"", ""("" and "")"" symbols are interpreted as defined in 1072 [RFC5234]. 1074 The "EBMLPathAtom" part of the "EBMLElementPath" MUST be equal to the 1075 "name" attribute of the "EBML Schema". 1077 The starting "PathDelimiter" of the path corresponds to the root of 1078 the "EBML Document". 1080 The "EBMLElementOccurrence" part is interpreted as an ABNF Variable 1081 Repetition. The repetition amounts correspond to how many times the 1082 "EBML Element" can be found in its "Parent Element". 1084 The "EBMLMinOccurrence" represents the minimum number of occurrences 1085 of this "EBML Element" within its "Parent Element". Each instance of 1086 the "Parent Element" MUST contain at least this many instances of 1087 this "EBML Element". If the "EBML Element" has an empty 1088 "EBMLParentPath" then "EBMLMinOccurrence" refers to constraints on 1089 the occurrence of the "EBML Element" within the "EBML Document". If 1090 "EBMLMinOccurrence" is not present then that "EBML Element" has an 1091 "EBMLMinOccurrence" value of 0. The semantic meaning of 1092 "EBMLMinOccurrence" within an "EBML Schema" is analogous to the 1093 meaning of "minOccurs" within an "XML Schema". "EBML Elements" with 1094 "EBMLMinOccurrence" set to "1" that also have a "default" value (see 1095 Section 13.1.5.8) declared are not REQUIRED to be stored but are 1096 REQUIRED to be interpreted, see Section 13.1.14. An "EBML Element" 1097 defined with a "EBMLMinOccurrence" value greater than zero is called 1098 a "Mandatory EBML Element". 1100 The "EBMLMaxOccurrence" represents the maximum number of occurrences 1101 of this "EBML Element" within its "Parent Element". Each instance of 1102 the "Parent Element" MUST contain at most this many instances of this 1103 "EBML Element". If the "EBML Element" has an empty "EBMLParentPath" 1104 then "EBMLMaxOccurrence" refers to constraints on the occurrence of 1105 the "EBML Element" within the "EBML Document". If 1106 "EBMLMaxOccurrence" is not present then that "EBML Element" has no 1107 maximum occurrence. The semantic meaning of "EBMLMaxOccurrence" 1108 within an "EBML Schema path" is analogous to the meaning of 1109 "maxOccurs" within an "XML Schema". 1111 The "VariableParentOccurrence" part is interpreted as an ABNF 1112 Variable Repetition. The repetition amounts correspond to the amount 1113 of unspecified "Parent Element" levels there can be between the 1114 "EBMLFixedParent" and the actual "EBMLElementPath". 1116 If the path contains an "EBMLPathAtomRecursive" part, the "EBML 1117 Element" can occur within itself recursively (see the 1118 Section 13.1.5.11). 1120 13.1.5.3. id 1122 The "Element ID" encoded as a "Variable Size Integer" expressed in 1123 hexadecimal notation prefixed by a "0x" that is read and stored in 1124 big-endian order. To reduce the risk of false positives while 1125 parsing "EBML Streams", the "Element IDs" of the "Root Element" and 1126 "Top-Level Elements" SHOULD be at least 4 octets in length. "Element 1127 IDs" defined for use at "Root Level" or directly under the "Root 1128 Level" MAY use shorter octet lengths to facilitate padding and 1129 optimize edits to "EBML Documents"; for instance, the "Void Element" 1130 uses an "Element ID" with a one octet length to allow its usage in 1131 more writing and editing scenarios. 1133 The "id" attribute is REQUIRED. 1135 13.1.5.4. minOccurs 1137 An integer expressing the minimum number of occurrences of this "EBML 1138 Element" within its "Parent Element". The "minOccurs" value MUST be 1139 equal to the "EBMLMinOccurrence" value of the "path". 1141 The "minOccurs" attribute is OPTIONAL. If the "minOccurs" attribute 1142 is not present then that "EBML Element" has a "minOccurs" value of 0. 1144 13.1.5.5. maxOccurs 1146 An integer expressing the maximum number of occurrences of this "EBML 1147 Element" within its "Parent Element". The "maxOccurs" value MUST be 1148 equal to the "EBMLMaxOccurrence" value of the "path". 1150 The "maxOccurs" attribute is OPTIONAL. If the "maxOccurs" attribute 1151 is not present then that "EBML Element" has no maximum occurrence, 1152 similar to "unbounded" in the XML world. 1154 13.1.5.6. range 1156 A numerical range for "EBML Elements" which are of numerical types 1157 (Unsigned Integer, Signed Integer, Float, and Date). If specified 1158 the value of the "EBML Element" MUST be within the defined range. 1159 See Section 13.1.5.6.1 for rules applied to expression of range 1160 values. 1162 The "range" attribute is OPTIONAL. If the "range" attribute is not 1163 present then any value legal for the "type" attribute is valid. 1165 13.1.5.6.1. Expression of range 1167 The "range" attribute MUST only be used with "EBML Elements" that are 1168 either "signed integer", "unsigned integer", "float", or "date". The 1169 "range" expression may contain whitespace for readability but 1170 whitespace within a "range" expression MUST NOT convey meaning. The 1171 expression of the "range" MUST adhere to one of the following forms: 1173 o "x-y" where x and y are integers or floats and "y" MUST be greater 1174 than "x", meaning that the value MUST be greater than or equal to 1175 "x" and less than or equal to "y". "x" MUST be less than "y". 1177 o ">x" where "x" is an integer or float, meaning that the value MUST 1178 be greater than "x". 1180 o ">=x" where "x" is an integer or float, meaning that the value 1181 MUST be greater than or equal to "x". 1183 o "". 1288 13.1.6. Element 1290 The "" element provides additional information about 1291 the "EBML Element". 1293 13.1.7. Attributes 1295 13.1.7.1. lang 1297 A "lang" attribute which is set to the [RFC5646] value of the 1298 language of the element's documentation. 1300 The "lang" attribute is OPTIONAL. 1302 13.1.7.2. type 1304 A "type" attribute distinguishes the meaning of the documentation. 1305 Values for the "" sub-element's "type" attribute MUST 1306 include one of the following: "definition", "rationale", "usage 1307 notes", and "references". 1309 The "type" attribute is OPTIONAL. 1311 13.1.8. Element 1313 The "" element provides information about restrictions 1314 to the allowable values for the "EBML Element" which are listed in 1315 "" elements. 1317 13.1.9. Element 1319 The "" element stores a list of values allowed for storage in 1320 the "EBML Element". The values MUST match the "type" of the "EBML 1321 Element" (for example "" cannot be a valid value 1322 for a "EBML Element" that is defined as an unsigned integer). An 1323 "" element MAY also store "" elements to further 1324 describe the "". 1326 13.1.10. Attributes 1328 13.1.10.1. label 1330 The "label" provides a concise expression for human consumption that 1331 describes what the "value" of the "" represents. 1333 The "label" attribute is OPTIONAL. 1335 13.1.10.2. value 1337 The "value" represents data that MAY be stored within the "EBML 1338 Element". 1340 The "value" attribute is REQUIRED. 1342 13.1.11. XML Schema for EBML Schema 1344 1345 1349 1350 1351 1352 1354 1355 1356 1357 1358 1359 1360 1362 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1384 1385 1386 1387 1388 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1403 13.1.12. Identically Recurring Elements 1405 An "Identically Recurring Element" is an "EBML Element" that MAY 1406 occur within its "Parent Element" more than once but that each 1407 recurrence within that "Parent Element" MUST be identical both in 1408 storage and semantics. "Identically Recurring Elements" are 1409 permitted to be stored multiple times within the same "Parent 1410 Element" in order to increase data resilience and optimize the use of 1411 "EBML" in transmission. For instance a pertinent "Top-Level Element" 1412 could be periodically resent within a data stream so that an "EBML 1413 Reader" which starts reading the stream from the middle could better 1414 interpret the contents. "Identically Recurring Elements" SHOULD 1415 include a "CRC-32 Element" as a "Child Element"; this is especially 1416 recommended when "EBML" is used for long-term storage or 1417 transmission. If a "Parent Element" contains more than one copy of 1418 an "Identically Recurring Element" which includes a "CRC-32 Element" 1419 as a "Child Element" then the first instance of the "Identically 1420 Recurring Element" with a valid CRC-32 value should be used for 1421 interpretation. If a "Parent Element" contains more than one copy of 1422 an "Identically Recurring Element" which does not contain a "CRC-32 1423 Element" or if "CRC-32 Elements" are present but none are valid then 1424 the first instance of the "Identically Recurring Element" should be 1425 used for interpretation. 1427 13.1.13. Textual expression of floats 1429 When a float value is represented textually in an "EBML Schema", such 1430 as within a "default" or "range" value, the float values MUST be 1431 expressed as Hexadecimal Floating-Point Constants as defined in the 1432 C11 standard [ISO.9899.2011] (see section 6.4.4.2 on Floating 1433 Constants). The following table provides examples of expressions of 1434 float ranges. 1436 +-------------------+-----------------------------------------+ 1437 | as decimal | as Hexadecimal Floating-Point Constants | 1438 +-------------------+-----------------------------------------+ 1439 | 0.0 | "0x0p+1" | 1440 | 0.0-1.0 | "0x0p+1-0x1p+0" | 1441 | 1.0-256.0 | "0x1p+0-0x1p+8" | 1442 | 0.857421875 | "0x1.b7p-1" | 1443 | -1.0--0.857421875 | "-0x1p+0--0x1.b7p-1" | 1444 +-------------------+-----------------------------------------+ 1446 Within an expression of a float range, as in an integer range, the 1447 "-" (hyphen) character is the separator between the minimal and 1448 maximum value permitted by the range. Hexadecimal Floating-Point 1449 Constants also use a "-" (hyphen) when indicating a negative binary 1450 power. Within a float range, when a "-" (hyphen) is immediately 1451 preceded by a letter "p", then the "-" (hyphen) is a part of the 1452 Hexadecimal Floating-Point Constant which notes negative binary 1453 power. Within a float range, when a "-" (hyphen) is not immediately 1454 preceded by a letter "p", then the "-" (hyphen) represents the 1455 separator between the minimal and maximum value permitted by the 1456 range. 1458 13.1.14. Note on the use of default attributes to define Mandatory EBML 1459 Elements 1461 If a "Mandatory EBML Element" has a default value declared by an 1462 "EBML Schema" and the value of the "EBML Element" is equal to the 1463 declared default value then that "EBML Element" is not required to be 1464 present within the "EBML Document" if its "Parent Element" is 1465 present. In this case, the default value of the "Mandatory EBML 1466 Element" MUST be read by the "EBML Reader" although the "EBML 1467 Element" is not present within its "Parent Element". 1469 If a "Mandatory EBML Element" has no default value declared by an 1470 "EBML Schema" and its "Parent Element" is present then the "EBML 1471 Element" MUST be present as well. If a "Mandatory EBML Element" has 1472 a default value declared by an "EBML Schema" and its "Parent Element" 1473 is present and the value of the "EBML Element" is NOT equal to the 1474 declared default value then the "EBML Element" MUST be present. 1476 This table clarifies if a "Mandatory EBML Element" MUST be written, 1477 according to if the "default" value is declared, if the value of the 1478 "EBML Element" is equal to the declared "default" value, and if the 1479 "Parent Element" is used. 1481 +---------------+---------------+---------------+-------------------+ 1482 | Is the | Is the value | Is the Parent | Then is storing | 1483 | default value | equal to | Element | the EBML Element | 1484 | declared? | default? | present? | REQUIRED? | 1485 +---------------+---------------+---------------+-------------------+ 1486 | Yes | Yes | Yes | No | 1487 | Yes | Yes | No | No | 1488 | Yes | No | Yes | Yes | 1489 | Yes | No | No | No | 1490 | No | n/a | Yes | Yes | 1491 | No | n/a | No | No | 1492 +---------------+---------------+---------------+-------------------+ 1494 13.2. EBML Header Elements 1496 This document contains definitions of all "EBML Elements" of the 1497 "EBML Header". 1499 13.2.1. EBML Element 1501 name: "EBML" 1503 path: "1*1(\EBML)" 1505 id: "0x1A45DFA3" 1507 minOccurs: 1 1509 maxOccurs: 1 1511 type: "Master Element" 1513 description: Set the "EBML" characteristics of the data to follow. 1514 Each "EBML Document" has to start with this. 1516 13.2.2. EBMLVersion Element 1518 name: "EBMLVersion" 1520 path: "1*1(\EBML\EBMLVersion)" 1522 id "0x4286" 1524 minOccurs: 1 1526 maxOccurs: 1 1528 range: not 0 1529 default: 1 1531 type: Unsigned Integer 1533 description: The version of "EBML" specifications used to create the 1534 "EBML Document". The version of "EBML" defined in this document is 1535 1, so "EBMLVersion" SHOULD be 1. 1537 13.2.3. EBMLReadVersion Element 1539 name: "EBMLReadVersion" 1541 path: "1*1(\EBML\EBMLReadVersion)" 1543 id: "0x42F7" 1545 minOccurs: 1 1547 maxOccurs: 1 1549 range: 1 1551 default: 1 1553 type: Unsigned Integer 1555 description: The minimum "EBML" version an "EBML Reader" has to 1556 support to read this "EBML Document". The "EBMLReadVersion Element" 1557 MUST be less than or equal to "EBMLVersion". 1559 13.2.4. EBMLMaxIDLength Element 1561 name: "EBMLMaxIDLength" 1563 path: "1*1(\EBML\EBMLMaxIDLength)" 1565 id "0x42F2" 1567 minOccurs: 1 1569 maxOccurs: 1 1571 range: >=4 1573 default: 4 1575 type: Unsigned Integer 1576 description: The "EBMLMaxIDLength Element" stores the maximum length 1577 in octets of the "Element IDs" to be found within the "EBML Body". 1578 An "EBMLMaxIDLength Element" value of four is RECOMMENDED, though 1579 larger values are allowed. 1581 13.2.5. EBMLMaxSizeLength Element 1583 name: "EBMLMaxSizeLength" 1585 path: "1*1(\EBML\EBMLMaxSizeLength)" 1587 id "0x42F3" 1589 minOccurs: 1 1591 maxOccurs: 1 1593 range: not 0 1595 default: 8 1597 type: Unsigned Integer 1599 description: The "EBMLMaxSizeLength Element" stores the maximum 1600 length in octets of the expression of all "Element Data Sizes" to be 1601 found within the "EBML Body". To be clear the "EBMLMaxSizeLength 1602 Element" documents the maximum 'length' of all "Element Data Size" 1603 expressions within the "EBML Body" and not the maximum 'value' of all 1604 "Element Data Size" expressions within the "EBML Body". "EBML 1605 Elements" that have an "Element Data Size" expression which is larger 1606 in octets than what is expressed by "EBMLMaxSizeLength ELEMENT" are 1607 invalid. 1609 13.2.6. DocType Element 1611 name: "DocType" 1613 path: "1*1(\EBML\DocType)" 1615 id "0x4282" 1617 minOccurs: 1 1619 maxOccurs: 1 1621 size: >0 1623 type: String 1624 description: A string that describes and identifies the content of 1625 the "EBML Body" that follows this "EBML Header". 1627 13.2.7. DocTypeVersion Element 1629 name: "DocTypeVersion" 1631 path: "1*1(\EBML\DocTypeVersion)" 1633 id "0x4287" 1635 minOccurs: 1 1637 maxOccurs: 1 1639 range: not 0 1641 default: 1 1643 type: Unsigned Integer 1645 description: The version of "DocType" interpreter used to create the 1646 "EBML Document". 1648 13.2.8. DocTypeReadVersion Element 1650 name: DocTypeReadVersion 1652 path: "1*1(\EBML\DocTypeReadVersion)" 1654 id "0x4285" 1656 minOccurs: 1 1658 maxOccurs: 1 1660 range: not 0 1662 default: 1 1664 type: Unsigned Integer 1666 description: The minimum "DocType" version an "EBML Reader" has to 1667 support to read this "EBML Document". The value of the 1668 "DocTypeReadVersion Element" MUST be less than or equal to the value 1669 of the "DocTypeVersion Element". 1671 13.2.9. DocTypeExtension Element 1673 name: "DocTypeExtension" 1675 path: "0*(\EBML\DocTypeExtension)" 1677 id "0x4281" 1679 minOccurs: 0 1681 type: "Master Element" 1683 description: A "DocTypeExtension" adds extra "Elements" to the main 1684 "DocType"+"DocTypeVersion" tuple it's attached to. An "EBML Reader" 1685 MAY know these extra "Elements" and how to use them. A 1686 "DocTypeExtension" MAY be used to iterate between experimental 1687 "Elements" before they are integrated in a regular "DocTypeVersion". 1688 Reading one "DocTypeExtension" version of a 1689 "DocType"+"DocTypeVersion" tuple doesn't imply one should be able to 1690 read upper values of this "DocTypeExtension". 1692 13.2.10. DocTypeExtensionName Element 1694 name: "DocTypeExtensionName" 1696 path: "1*1(\EBML\DocTypeExtension\Name)" 1698 id "0x4283" 1700 minOccurs: 1 1702 maxOccurs: 1 1704 size: >0 1706 type: String 1708 description: The name of the "DocTypeExtension" to identify it from 1709 other "DocTypeExtension" of the same "DocType"+"DocTypeVersion" 1710 tuple. A "DocTypeExtensionName" value MUST be unique within the 1711 "EBML Header". 1713 13.2.11. DocTypeExtensionVersion Element 1715 name: "DocTypeExtensionVersion" 1717 path: "1*1(\EBML\DocTypeExtension\Version)" 1718 id "0x4284" 1720 minOccurs: 1 1722 maxOccurs: 1 1724 range: not 0 1726 type: Unsigned Integer 1728 description: The version of the "DocTypeExtension". Different 1729 "DocTypeExtensionVersion" values of the same 1730 "DocType"+"DocTypeVersion"+"DocTypeExtensionName" tuple MAY contain 1731 completely different sets of extra "Elements". An "EBML Reader" MAY 1732 support multiple versions of the same "DocTypeExtension", only one or 1733 none. 1735 13.3. Global Elements 1737 EBML defines these "Global Elements" which MAY be stored within any 1738 "Master Element" of an "EBML Document" as defined by their "Element 1739 Path". 1741 13.3.1. CRC-32 Element 1743 name: CRC-32 1745 path: "*1((1*\)\CRC-32)" 1747 id: "0xBF" 1749 minOccurs: 0 1751 maxOccurs: 1 1753 size: 4 1755 type: Binary 1757 description: The "CRC-32 Element" contains a 32-bit Cyclic Redundancy 1758 Check value of all the "Element Data" of the "Parent Element" as 1759 stored except for the "CRC-32 Element" itself. When the "CRC-32 1760 Element" is present, the "CRC-32 Element" MUST be the first ordered 1761 "EBML Element" within its "Parent Element" for easier reading. All 1762 "Top-Level Elements" of an "EBML Document" that are "Master Elements" 1763 SHOULD include a "CRC-32 Element" as a "Child Element". The CRC in 1764 use is the IEEE-CRC-32 algorithm as used in the [ISO.3309.1979] 1765 standard and in section 8.1.1.6.2 of [ITU.V42.1994], with initial 1766 value of "0xFFFFFFFF". The CRC value MUST be computed on a little 1767 endian bitstream and MUST use little endian storage. 1769 13.3.2. Void Element 1771 name: Void 1773 path: "*((*\)\Void)" 1775 id: "0xEC" 1777 minOccurs: 0 1779 type: Binary 1781 description: Used to void damaged data or to avoid unexpected 1782 behaviors when using damaged data. The content is discarded. Also 1783 used to reserve space in a sub-element for later use. 1785 14. Considerations for Reading EBML Data 1787 The following scenarios describe events to consider when reading 1788 "EBML Documents" and the recommended design of an "EBML Reader". 1790 If a "Master Element" contains a "CRC-32 Element" that doesn't 1791 validate, then the "EBML Reader" MAY ignore all contained data except 1792 for "Descendant Elements" that contain their own valid "CRC-32 1793 Element". 1795 If a "Master Element" contains more occurrences of a "Child Master 1796 Element" than permitted according to the "maxOccurs" and "recurring" 1797 attributes of the definition of that "Element" then the occurrences 1798 in addition to "maxOccurs" MAY be ignored. 1800 If a "Master Element" contains more occurrences of a "Child Element" 1801 that is not a "Master Element" than permitted according to the 1802 "maxOccurs" attribute of the definition of that "Element" then all 1803 but the instance of that "Element" with the smallest byte offset from 1804 the beginning of its "Parent Element" SHOULD be ignored. 1806 15. IANA Considerations 1808 15.1. CELLAR EBML Element ID Registry 1810 This document creates a new IANA Registry called "CELLAR EBML Element 1811 ID Registry". 1813 Element IDs are described in section "Element ID". Element IDs are 1814 encoded using the VINT mechanism described in section Section 5 can 1815 be between one and five octets long. Five octet long Element IDs are 1816 possible only if declared in the header. 1818 This IANA Registry only applies to "Elements" contained at least in 1819 the "EBML Header", thus including "Global Elements". "Elements" only 1820 found in the "EBML Body" have their own set of independent "Element 1821 IDs" and are not part of this IANA Registry. 1823 The VINT Data value of one-octet Element IDs MUST be between 0x01 and 1824 0x7E. These items are valuable because they are short, and need to 1825 be used for commonly repeated elements. Values from 1 to 126 are to 1826 be allocated according to the "RFC Required" policy [RFC8126]. 1828 The VINT Data value of two-octet Element IDs MUST be between 0x007F 1829 and 0x3FFE. Numbers are be allocated within this range according to 1830 the "Specification Required" policy [RFC8126]. 1832 The numbers 0x3FFF and 0x4000 are RESERVED. 1834 The VINT Data value of three-octet Element IDs MUST be between 0x4001 1835 and 0x1FFFFE. Numbers may be allocated within this range according 1836 to the "First Come First Served" policy [RFC8126]. 1838 The numbers 0x1FFFFF and 0x200000 are RESERVED. 1840 Four octet Element IDs are numbers between 0x2000001 and 0xFFFFFFE. 1841 Four octet Element IDs are somewhat special in that they are useful 1842 for resynchronizing to major structures in the event of data 1843 corruption or loss. As such four octet Element IDs are split into 1844 two categories. Four octet Element IDs whose lower three octets (as 1845 encoded) would make printable 7-bit ASCII values MUST be allocated by 1846 the "Specification Required" policy. Sequential allocation of values 1847 is not required: specifications SHOULD include a specific request, 1848 and are encouraged to do early allocations. 1850 To be clear about the above category: four octet Element IDs always 1851 start with hex 0x10 to 0x1F, and that octet may be chosen so that the 1852 entire number has some desirable property, such as a specific CRC. 1853 The other three octets, when ALL having values between 0x21 (33, 1854 ASCII !) and 0x7e (126, ASCII ~), fall into this category. 1856 Other four octet Element IDs may be allocated by the "First Come 1857 First Served" policy. 1859 The numbers 0xFFFFFFF and 0x1000000 are RESERVED. 1861 Five octet Element IDs (values from 0x10000001 upwards) are RESERVED 1862 according to the "Experimental Use" policy [RFC8126]: they may be 1863 used by anyone at any time, but there is no coordination. 1865 ID Values found in this document are assigned as initial values as 1866 follows: 1868 +------------+-------------------------+----------------------------+ 1869 | ID | Element Name | Reference | 1870 +------------+-------------------------+----------------------------+ 1871 | 0x1A45DFA3 | EBML | Described in Section | 1872 | | | 13.2.1 | 1873 | 0x4286 | EBMLVersion | Described in Section | 1874 | | | 13.2.2 | 1875 | 0x42F7 | EBMLReadVersion | Described in Section | 1876 | | | 13.2.3 | 1877 | 0x42F2 | EBMLMaxIDLength | Described in Section | 1878 | | | 13.2.4 | 1879 | 0x42F3 | EBMLMaxSizeLength | Described in Section | 1880 | | | 13.2.5 | 1881 | 0x4282 | DocType | Described in Section | 1882 | | | 13.2.6 | 1883 | 0x4287 | DocTypeVersion | Described in Section | 1884 | | | 13.2.7 | 1885 | 0x4285 | DocTypeReadVersion | Described in Section | 1886 | | | 13.2.8 | 1887 | 0x4281 | DocTypeExtension | Described in Section | 1888 | | | 13.2.9 | 1889 | 0x4283 | DocTypeExtensionName | Described in Section | 1890 | | | 13.2.10 | 1891 | 0x4284 | DocTypeExtensionVersion | Described in Section | 1892 | | | 13.2.11 | 1893 | 0xBF | CRC-32 | Described in Section | 1894 | | | 13.3.1 | 1895 | 0xEC | Void | Described in Section | 1896 | | | 13.3.2 | 1897 +------------+-------------------------+----------------------------+ 1899 15.2. CELLAR EBML DocType Registry 1901 This document creates a new IANA Registry called "CELLAR EBML DocType 1902 Registry". 1904 DocType values are described in Section 13.1.3.1. DocTypes are ASCII 1905 strings, defined in Section 8.4, which label the official name of the 1906 "EBML Document Type". The strings may be allocated according to the 1907 "First Come First Served" policy. 1909 The use of ASCII corresponds to the types and code already in use, 1910 the value is not meant to be visible to the user. 1912 DocType string values of "matroska" and "webm" are RESERVED to the 1913 IETF for future use. These can be assigned via the "IESG Approval" 1914 or "RFC Required" policies [RFC8126]. 1916 16. References 1918 16.1. Normative References 1920 [IEEE.754.1985] 1921 Institute of Electrical and Electronics Engineers, 1922 "Standard for Binary Floating-Point Arithmetic", 1923 IEEE Standard 754, August 1985. 1925 [ISO.3309.1979] 1926 International Organization for Standardization, "Data 1927 communication - High-level data link control procedures - 1928 Frame structure", ISO Standard 3309, 1979. 1930 [ISO.9899.2011] 1931 International Organization for Standardization, 1932 "Programming languages - C", ISO Standard 9899, 2011. 1934 [ITU.V42.1994] 1935 International Telecommunications Union, "Error-correcting 1936 Procedures for DCEs Using Asynchronous-to-Synchronous 1937 Conversion", ITU-T Recommendation V.42, 1994. 1939 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1940 RFC 20, DOI 10.17487/RFC0020, October 1969, 1941 . 1943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1944 Requirement Levels", BCP 14, RFC 2119, 1945 DOI 10.17487/RFC2119, March 1997, 1946 . 1948 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1949 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1950 . 1952 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1953 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1954 2003, . 1956 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1957 Specifications: ABNF", STD 68, RFC 5234, 1958 DOI 10.17487/RFC5234, January 2008, 1959 . 1961 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1962 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1963 September 2009, . 1965 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1966 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1967 . 1969 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1970 Writing an IANA Considerations Section in RFCs", BCP 26, 1971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1972 . 1974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1976 May 2017, . 1978 [W3C.REC-xml-20081126] 1979 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1980 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1981 Edition)", World Wide Web Consortium Recommendation REC- 1982 xml-20081126, November 2008, 1983 . 1985 16.2. Informative References 1987 [W3C.REC-xmlschema-0-20010502] 1988 Fallside, D., "XML Schema Part 0: Primer", World Wide Web 1989 Consortium Recommendation REC-xmlschema-0-20010502, May 1990 2001, 1991 . 1993 16.3. URIs 1995 [1] https://github.com/Matroska-Org/matroska-specification/ 1997 [2] https://tools.ietf.org/html/bcp14 1999 Authors' Addresses 2001 Steve Lhomme 2003 Email: slhomme@matroska.org 2004 Dave Rice 2006 Email: dave@dericed.com 2008 Moritz Bunkus 2010 Email: moritz@bunkus.org