Subject: [Cellar] recent CELLAR documents

From: Dave Rice <[email-masked]>
Date: Sat, 9 Jul 2016 14:34:00 -0400

Hi all,

I wanted to point out the posting of three documents in https://datatracker.ietf.org/wg/cellar/documents/.

EBML: https://datatracker.ietf.org/doc/draft-lhomme-cellar-ebml/
Matroska: https://datatracker.ietf.org/doc/draft-lhomme-cellar-matroska/
FF Video Codec 1: https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/

All three documents are produced from the three corresponding github repositories by their Makefile using mmark. For EBML and FFV1 this Makefile and rfc build process are merged into the repo. For Matroska that process is still in a pull request at https://github.com/Matroska-Org/matroska-specification/pull/31. Moritz, Ashley and I crammed on this work yesterday in order to submit the RFC draft by the IETF96 deadline, but this document is by far the messiest of the three and also the most active presently.

IIUC we can continue to work on these specs in our repositories but are not permitted to upload new RFC drafts until after IETF96. Does discussion at the IETF 96 cellar meeting focus on the documents already submitted or upon any more recent work?

Also I realize that the Matroska specification is massive. Currently at 220 pages and likely only going to get bigger. Is there any issue with size? For instance should it be split to move the Matroska Tagging standard to a separate document?

Best Regards,
Dave Rice

---

From: hubblec4 <[email-masked]>
Date: Sun, 10 Jul 2016 12:37:30 +0200

Hi all

> Matroska: https://datatracker.ietf.org/doc/draft-lhomme-cellar-matroska/
Is there any chance to change the WRONG element names (from "ChapString" 
to "ChapProcessData") to the correct element names?
>
>
> Best Regards,
> Dave Rice
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

kind rigards
Martin

---

From: Dave Rice <[email-masked]>
Date: Tue, 12 Jul 2016 11:34:41 -0400

Hi,

> On Jul 10, 2016, at 6:37 AM, hubblec4 <[email-masked]> wrote:
> 
> Hi all
> 
> 
> Is there any chance to change the WRONG element names (from "ChapString" to "ChapProcessData") to the correct element names?

Do you have a citation for the consideration of these Element Names being incorrect? The documentation and related libraries uses these terms consistently.
Dave

---

From: hubblec4 <[email-masked]>
Date: Wed, 13 Jul 2016 09:10:06 +0200

Hi all

> Do you have a citation for the consideration of these Element Names being incorrect? The documentation and related libraries uses these terms consistently.
Citation, no. But I see in the old and new style of the spec's that the 
elements still incorrect named.
"ChapString" is not a valid XML-node.
When a documantation use this "short" name, ok. But in the spec's it 
should be correct named.

kind regards
Martin

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 13 Jul 2016 09:20:51 +0200

Hey,

> "ChapString" is not a valid XML-node.

I'm not entirely sure what you mean, but I assume you're thinking about
the XML format MKVToolNix uses for chapters. The names used therein may
NOT be the official element names according to the specification! The
specification (and therefore the official element names) is what was on
the web page www.matroska.org and has now been converted into the
repository on GitHub.

Yes, that can be confusing. The reason the names mkvmerge uses are
different is that I thought it would be easier for humans to remember
that mkvmerge requires all chapter element names to start with <Chapter…
They're often the same but sometimes they just aren't.

I will likely implement a compatibility layer in mkvmerge sometime which
will make mkvmerge accept both the official element names as well as the
old ones.

> When a documantation use this "short" name, ok. But
> in the spec's it should be correct named.

ChapString is the correct name according to the specs.

Kind regards,
mosu

---

From: hubblec4 <[email-masked]>
Date: Wed, 13 Jul 2016 09:39:44 +0200

Hi all

> ChapString is the correct name according to the specs.
Ok, the specs say "ChapString" and you mean that is the correct form, 
and "ChapterString" is not correct but mkvmerge use this form, cause its 
easier for humen.

mkvmerge give me an error message when trying to load a XML with 
"ChapString" as an element name.
(attached picture).

(now I'm again confused)

kind regards
Martin

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 13 Jul 2016 09:53:13 +0200

Hey,

> Ok, the specs say "ChapString" and you mean that is the correct form

Yes.

> and "ChapterString" is not correct but mkvmerge use this form, cause
> its easier for humen.

Yes.

> mkvmerge give me an error message when trying to
> load a XML with "ChapString" as an element name.
> (attached picture).

Yes, obviously. Like I said: mkvmerge uses names that are different from
the official names in the spec. That's simply how it currently is. Just
use <ChapterString> when writing XML files for mkvmerge and use
ChapString when talking about the specifications.

Kind regards,
mosu

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 14 Jul 2016 12:20:05 -0700

> IIUC we can continue to work on these specs in our repositories but are not permitted to upload new RFC drafts until after IETF96. Does discussion at the IETF 96 cellar meeting focus on the documen…

To answer this question, you should generally expect that people have 
had time to review what was submitted (that's the reason for the 
submission moratorium). There's no reason to pretend more recent changes 
haven't happened, but you should take into consideration that not 
everyone will have know about/followed them.

> Also I realize that the Matroska specification is massive. Currently at 220 pages and likely only going to get bigger. Is there any issue with size? For instance should it be split to move the Matr…

The IETF has published larger documents, though not many. If there are 
logical ways to split it up, that may it easier to get a smaller 
document containing the important things through and published more 
quickly. Though one question to ask might be how much of what is 
specified is even necessary at all.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 15 Jul 2016 21:10:58 -0700

> EBML: https://datatracker.ietf.org/doc/draft-lhomme-cellar-ebml/

I thought it might be helpful to have some detailed feedback early in 
the process so I reviewed the EBML document. These are just my opinions 
as an individual contributor. This should not be taken as a formal chair 
review in any way, and is by no means a complete review, as I am sure 
I've missed things. At a minimum, while I noted some typos and 
grammatical faults, that wasn't my focus, and there are still plenty of 
places the language could be improved.

In general, this document uses a lot of terms and concepts before 
defining or explaining them, without providing cross-references, 
requiring a good deal of flipping back-and-forth to understand 
everything. While adding cross-references is one useful step, a more 
logical organization of the document to explain concepts before 
introducing constructs which rely on them would reduce the amount of 
back-and-forth required and make things much easier to understand. I've 
included some specific suggestions of what should move where below.

Detailed comments by section follow.

== Abstract ==

> "...this document defines an EBML Schema to convey the semantics..."
It defines a single schema, or it defines HOW schemas convey semantics?

> "EBML is designed as a binary equivalent to XML and utilizes a storage-efficient approach..."
I would replace every instance of the word "utilize" (or its 
conjugations) in this document with "use".

=== EBML specifications ===

I would just remove the entire top-level section here, so that 
"Introduction" is Section 1 instead of 1.1, "Notations and Conventions" 
is Section 2 instead of 1.2, etc.

== Introduction ==

Should expand/define XML.

== Notation and Conventions ==

The reference to RFC2119 is sufficient, you don't also need the URL.

== Security Considerations ==

> "...only marginally useful and effective data integrity options..."
This sentence fragment should be turned into an independent sentence.

> "Attacks on an EBML reader may include:"
List formatting.

This section refers to a number of things defined elsewhere in the 
document. You should probably either a) provide forward references to 
the places where these things are defined or b) move this section to the 
end of the document, after those things are defined.

A number of the things listed as "attacks" are simply things you said 
someone writing an EBML Document MUST NOT do (or not doing things you 
said they MUST do). But in none of those cases do you say what is 
expected of someone reading a document containing these attacks.

== Variable Size Integer ==

> "...shall be referred to..."
"SHALL" is an RFC 2119 keyword, but appears here in lower case. Nothing 
in 2119 explicitly says that the case matters, so the careful document 
author will refrain from using these words in non-2119 contexts (i.e., 
unless they intentionally wish to impose a normative requirement). This 
is the subject of some debate 
(<https://www.ietf.org/mail-archive/web/ietf/current/msg73338.html>), 
but if you do the careful thing, you will avoid getting your document 
drawn into the argument and getting held up until it is resolved (which 
may never happen).

= VINT_WIDTH =

How are these bits packed into octets? (the "VINT Examples" section 
makes this clear, but you shouldn't just rely on examples) Should there 
be a limit on the number of zero-value bits? If so, what happens if this 
limit is exceeded? What are you supposed to do if attempting to read a 
length (e.g., of a String, which has no defined maximum length) and the 
entire rest of the file consists of zero bytes?

The document later defines some context-specific limits, but never 
answers the question about what you're supposed to do if these limits 
are violated for any context.

= VINT_DATA =

> "...one bit per octet..."
It would be clearer to say "one out of eight bits", since the bit is 
not, in fact, taken out of each octet.

> "...then VINT_DATA may be zero-padded..."
Another RFC 2119 keyword ("MAY"). But why is this just a MAY? What other 
things are you allowed to do if "the number of bits required is less 
than the bit size of VINT_DATA [sic]"?

> "...a big-endian unsigned integer."
It might be useful to state up-front that these Variable Size Integers 
are only unsigned (so, e.g., the reader is not left wondering if instead 
of zero-padding above they are expected to sign-extend, or something 
else silly).

= VINT Examples =

This switches from talking about "octet lengths" as is done in the 
"VINT_WIDTH" section to "octet widths". You should be consistent.

The "Size" column should make it clear that this is just the VINT_DATA 
size (in bits).

== Element ID ==

> "By default, EBML Element IDs may be encoded... although Element IDs of greater lengths MAY be used..."
MAY?

You should include a forward reference to EBMLMaxIDLength.

> "The VINT_DATA component of the Element ID MUST NOT be set to either all zero values or all one values."
What is an implementation supposed to do if it encounters a file that 
violates this restriction? What is the purpose of reserving the various 
all-ones Element IDs? Or the zero Element ID, for that matter?

> "The VINT_DATA component of the Element ID MUST be encoded at the shortest valid length."
What is the definition of "valid"? Is the Element ID 0100 0000 0111 1111 
allowed? Although the shortest length required to encode the integer 127 
is one octet, that encoding has VINT_DATA set to all ones, which you 
just said I MUST NOT do. So is one the shortest valid length or two? I 
can guess what you meant by looking at the Number of Possible Element 
IDs in the table below, but it would be better to say so explicitly.

> "The octet length of an Element ID determines its EBML Class."
I'd add, "...as defined in Table XX" (and give the table a number and a 
caption).

Should you say something about the classes for Element IDs of longer 
lengths, since you explicitly allow them above with an appropriate 
EBMLMaxIDLength declaration?

== Element Data Size ==

You should include a forward reference to EBMLMaxSizeLength.

> "...the VINT_DATA component of the Element Data Size is not required to be encoded at the shortest valid length."
"REQUIRED" is a 2119 keyword, but "NOT REQUIRED" is not, so you may wish 
to rephrase this. You may also wish to mention the redundant, equivalent 
encodings as a potential side channel in your Security Considerations 
section.

> "...both store a semantically equal value."
It might be helpful to the reader to explicitly say what that value is.

You should define or forward reference what an "EBML Data Type" is. This 
is the only mention of it in the document. Did you mean EBML Element Type?

> "...definition of the EBML Element Types."
Why is this plural?

> "If an Empty Element has a 'default' value declared then that default value MUST be interpreted as the value of the Empty Element. If an Empty Element has no 'default' value declared then the semantic meaning of Empty Element is defined as part of the definition of the EBML Element Types."
This part is confusingly worded. The normative requirement combined with 
passive voice makes it unclear on whom this requirement is being 
imposed. I think what you are trying to say is that first, you check to 
see if the definition of the Element ID corresponding to this element 
has a declared default value, and, if not, you then take the default 
from the Element Type associated with that Element ID. But since neither 
sentence mentions Element ID, this is pretty unclear.

> "...SHOULD NOT be used unnecessarily."
Why not MUST? Can you describe reasons someone might reasonably violate 
this? What qualifies as "necessary"?

> "...MUST be a Master-element..."
I don't think hyphenation is what you want here (hyphenation is used in 
phrases that function as adjectives or adverbs, not phrases that 
function as nouns). Might it be clearer to say that unknown Element Data 
Size values MUST NOT be used unless the element is a Master Element?

> "...MAY only..."
This is not how 2119 MAY is meant to work. I'd rephrase with a different 
keyword, e.g., again, "...MUST NOT use an unknown size unless the 
'unknownsizeallowed' attribute... is set to true." You should forward 
reference the definition of the "unknownsizeallowed" attribute.

How does someone know if an element is a valid sub-element of a Master 
Element? Can you forward reference some text that defines this?

> "The end of a Master-element with unknown size is determined by the beginning of the next element that is not a valid sub-element of that Master-element."
Is an invalid element ID (the all-zeros or all-ones element IDs) 
considered the beginning of an element that is not a valid sub-elmeent 
of a Master Element?

== EBML Element Types ==

The section header says "EBML Element Type", but earlier text used both 
"EBML Data Type" and "EBML Element Type", and the tables in this section 
use "Element Data Type". You should be consistent.

> "Each defined EBML Element MUST have a declared Element Type."
What would it mean for an EBML Element to be "defined" but not have a 
declared Element Type? What does it mean to "have" that declaration? 
I.e., what normative requirement are you actually attempting to impose 
here? How does someone know that they have met it?

> "...may be constrained..."
MAY?

> "An Signed [sic] Integer Element with a zero-octet length represents an integer value of zero."
This is only true for Element IDs that do not have a declared default 
value, right? It would be a good idea to explicitly say that, otherwise 
it appears to contradict the earlier text in the "Element Data Size" 
section. The same applies for the defaults declared for every other 
Element Type.

You may also wish to mention how the signed integers are stored. I would 
assume two's complement, but that's not explicitly stated.

> "A Float Element MUST declare of length of..."
You meant "...a length of..."

> "A Float Elements stores a floating-point number as defined in IEEE 754."
You meant "A Float Element stores...." You should include a normative 
reference to IEEE 754.

> "A String Element may declare any length from zero to 'VINTMAX'."
MAY? VINTMAX is not a single value. Its value depends on the octet width 
(length?) of the Element Data Size. Is there any restriction on this 
octet width? If not, I would just phrase this as, "A String Element can 
have any length, including zero." However, it is obvious that no 
implementation will be able to support strings of completely arbitrarily 
length. Is there some required minimum that decoders are required to 
handle? When is a 32-bit system with no more than 4 GB of RAM justified 
in rejecting a string as too large? How about an embedded media player 
in someone's television? How would someone writing an EBML document know 
when writing a string if all decoders will be able to handle it?

> "A String Element may either be empty (zero-length)..."
MAY? The previous Element Types all define what it means when the length 
is zero in the section on "Length". Should you do the same for the 
string types?

Reference for ASCII?

What is a decoder supposed to do when it encounters a string with octets 
outside of the Printable ASCII range (excluding zero octets at the end)?

> "Octets with all bits set to zero may follow the string value when needed."
MAY? When is this "needed"? Are these zero bytes meant to be part of the 
string, or is a string with one or more zero bytes appended to it 
semantically equivalent to a string without any zero bytes appended to 
it? If so, in your Security Considerations section, you may wish to 
mention these equivalent values as a potential side channel.

All of the above questions and comments for the String Element Type also 
apply to the UTF-8 Element Type. Again, the reference to RFC2279 is 
sufficient without the extra URL (which does not even point to the same 
place as the URL for 2119). Should the reference to RF2279 be normative? 
Can the element data be interpreted or validated without understanding 
the referenced document?

The "Date" Element Type says "Endianness: None", but Signed Integers 
were specified to be big endian.

> "The Data Element MUST contain a Signed Integer..."
What does it meant to "contain a Signed Integer" here, given that this 
is the definition of an Element Type, and a Signed Integer is also an 
Element Type. Maybe it would make more sense to say it stores an integer 
in the same format as a Signed Integer?

You should provide a normative reference for UTC.

> "A Master-element may declare any length from zero to 'VINTMAX'."
Same comments as for strings.

> "The Master-element may also use an unknown length. See the section on Element Data Size for rules that apply to elements of unknown length."
MAY? This should include an explicit section cross-reference.

> "Elements contained within a Master-element must be defined for use at levels greater than the level of the Master-element."
MUST? What is a level? What does it mean to be defined for use at a 
level? What is the level of the Master Element? What does it mean to be 
valid at a level? You should forward reference text that explains all of 
this.

> "...all contained Elements must be valid at level 3."
MUST?

> "For instance is a Master-element..."
You meant, "For instance, if a Master Element..."

> "Element Data stored within Master-elements SHOULD only consist of EBML Elements and SHOULD NOT contain any data that is not part of an EBML Element."
Why not MUST? Can you describe reasons someone might reasonably violate 
these SHOULDs? You've specified _when_ they are allowed to, but not 
_why_. Is the "is permitted" case the only case in which it is 
permitted? If so, you should structure the normative language to make 
that clear. What does it mean for EBML to be "used in transmission or 
streaming"? If someone sends you an EBML document over HTTP, and you 
save it to disk, are you required to strip out any non-element data from 
Master Elements?

> "Any data contained with a Master-element that is not part of an Element SHOULD be ignored."
Why not MUST? Can you describe reasons someone might reasonably violate 
this SHOULD? Also, you meant "within", not "with". Also, to be pedantic, 
any data contained within a Master Element _is_ part of an element: the 
Master Element that contains it. Otherwise you are violating the 
"...MUST NOT contain any data that is not part of an EBML Element" in 
the "EBML Document" section below.

In your Security Considerations section, you may wish to mention this 
data as a potential side channel.

> "The contents of a Binary element should not be interpreted by the EBML parser."
What is an EBML parser? This is the first mention of it in the document.

== EBML Document ==

> "An EBML Document MUST start with an EBML Header which declares significant characteristics of the entire EBML Body."
Is the "which" clause meant to be restrictive or unrestrictive?

> "...MAY only..."
This is not how 2119 MAY is meant to work.

Since the concept of Master Element and level is used in multiple places 
in the text prior to this section, it may be helpful to move this short 
paragraph earlier in the document (possibly expanding it with additional 
material required to understand the subsequent text without forward 
references).

= EBML Header =

> "The EBML Header may be considered as analogous to an XML Declaration."
MAY?

> "All EBML Documents MUST begin with a valid EBML Header."
You already said this in the preceding section.

> "The EBML Header documents the EBML Schema (also known as the EBML DocType) that may be used to semantically interpret the structure and meaning of the EBML Document."
MAY? What else would you use? What would you do if you didn't use it?

> "The EBML Header consists of a single Master-element with an Element ID of 'EBML'."
Previously, you said, "The Element ID MUST be encoded as a Variable Size 
Integer." How is 'EBML' encoded as a Variable Size Integer? I assume 
what you actually meant is that one is supposed to take the numeric 
Element ID frame the table of the element _named_ EBML in Section 
1.11.2, but since the reader hasn't seen that table yet, there's no 
forward reference, a name is not an ID, and nowhere do you explain how 
those IDs were derived, this is all pretty unclear.

> "The EBML Header MUST ONLY contain EBML Elements that are defined as part of the EBML Specification."
ONLY is not a 2119 keyword (though at least in this case, "only" is 
consistent with the use of 2119 MUST). What is "the EBML Specification"? 
I would just say, "...this document." Can an EBML Header contain an EBML 
Header element? Can it contain an EBML Body element? Both are defined in 
this document.

> "All EBML Elements within the EBML Header MUST NOT utilize any Element ID with a length greater than 4 octets.  All EBML Elements within the EBML Header MUST NOT utilize any Element Data Size with a length greater than 4 octets."
What is a decoder supposed to do if these restrictions are violated?

= EBML Body =

> "All data of an EBML Document following the EBML Header may be considered the EBML Body."
MAY? How else would you consider it?

> "The end of the EBML Body, as well as the end of the EBML Document that contains the EBML Body, is considered as whichever comes first: the beginning of a new level 0 EBML Header or the end of the file."
Is it possible to have a non-level-0 EBML Header? Can an EBML Body 
contain an EBML Header? Can it contain another EBML Body?

> "...MAY only..."
This is not how 2119 MAY is meant to work.

= EBML Schema =

> "...XML Schema [1]..."
This URL should probably instead be at least an informative reference.

> "An EBML Schema must be expressed as well-formed XML."
MUST? Although you give a URL for XML above, I think this statement 
means it needs to be a normative reference.

Should there be an XML Schema for valid EBML Schemas?

> "An EBML Document Type is identified by a unique string stored within the EBML Header element called DocType; for example 'matroska' or 'webm'."
What does it mean to be unique? How is this string stored within the 
EBML Header? Is DocType an EBML Element? If so, you should call it that, 
instead of just a string, and provide a forward reference.

> "...which are defined in the section on Section 1.11.1.1."
Delete "the section on". Did you mean "that" instead of "which"?

> "...but MUST NOT conflict is the definitions..."
You meant "...with the definitions...."

> "Within the EBML Schema each EBML Element is defined to occur at a specific level."
This and the following description of Global EBML Elements, Root 
Element, and Top-Level Elements would have answered a number of the 
questions I raised above if presented earlier in the document.

> "...specificied..."
Typo.

> "...specifiied..."
Typo.

> "...the Child EBML Element refers to the EBML Elements..."
Plural/singular mis-match.

> "...that may be immediately contained within that Master-element."
MAY?

> "...the Parent EBML Element may be identified..."
MAY? How else would you identify it?

> "The only exception for this rule are Global EBML Elements which may occur within any Parent EBML Element within the restriction of the Global EBML Element's range declaration."
MAY? Is the which clause meant to be restrictive or unrestrictive?

> "An EBML Schema MUST declare exactly one Element at Level 0 (referred to as the Root Element) that MUST occur exactly once within an EBML Document. The Root Element MUST be mandatory (with minOccurs set to 1) and MUST be defined to occur exactly once (maxOccurs set to 1)."
Is the second sentence saying the same thing as the first sentence, or 
are these different requirements? If so, how do they differ? You should 
provide forward references to minOccurs and maxOccurs.

> "Note that the EBML and Void Elements may also occur at Level 0 but are not considered to be Root Elements."
Delete "Note that". You should provide a forward reference for Void 
Elements.

> "...in the Section 1.11.2 section."
Delete the second "section".

= EBML Schema Element Attributes =

> "...'<EBMLSchema>' uses the following attributes to define the EBML Schema:"
These attributes are not the whole definition of an EBML Schema, surely. 
I'd just end the sentence after "attributes".

> "Elements may be introduced and deprecated by using the "minver" and "maxver" attributes of ."
Broken cross-reference.

> "The value of the name MUST be in the form of an NCName as defined by the XML Schema specification [3]."
[3] should be a normative reference, not just a URL.

> "...or may occur..."
MAY?

> "If the "global" attribute is not expressed..."
What does it mean for an attribute to be "expressed"? Did you just mean 
"present"?

> "The Element ID expressed in hexadecimal notation prefixed by a '0x'."
Is this meant to be the Variable Size Integer encoding of the element 
ID, or the the integer that that encoding encodes? From the examples, I 
believe you mean the former, but you should say so explicitly rather 
than requiring someone to work it out from the examples. If it is the 
former, you should also specify the byte order, since the definition of 
the Variable Size Integer merely specifies how it is encoded, bit-by-bit 
but here you are giving a single large integer value. Given that 
everything else is big-endian (except the CRC!), I can guess, but I 
shouldn't have to guess.

> "An integer to express the minimal number of occurrences that the EBML Element MUST occur within its Parent Element if its Parent Element is used."
That's pretty tortured. How about, "An integer expressing the minimum 
number of occurrences of this EBML Element within its Parent Element. 
Each instance of the Parent Element MUST contain at least this many 
instances of this Element." What is one expected to do if it does not 
contain this many?

> "If the Element has no Parent Level (as is the case with Elements at Level 0), then minOccurs refers to constaints on the Element's occurrence within the EBML Document."
Earlier you said there had to be exactly one element at level 0, and 
that it could only occur once, and also that its minOccurs had to be set 
to 1. So why is this sentence necessary? What is the point it's trying 
to make?

> "If the minOccurs attribute is not expressed for that Element then that Element shall be considered to have a minOccurs value of 0. This value of minOccurs MUST be a positive integer."
These two sentences seem to literally say that a minOccurs value of 0 
MUST be a positive integer. Did you mean "the" instead of "this"? Does 
that mean that the only way to express a minOccurs of value of 0 is to 
omit the attribute?

> "...see the Section 1.11.1.6."
Delete "the".

> "A value to express the maximum number of occurrences that the EBML Element MAY occur within its Parent Element if its Parent Element is used."
Just as tortured as above, but can be fixed in a similar way. What is 
one expected to do if there are more than this many occurrences? If 
maxOccurs is a positive integer, and maxOccurs instances of the element 
have already been encountered within a Master Element with an unknown 
size, is the another instance of this element considered "...the 
beginning of the next element that is not a valid sub-element of that 
Master-element"?

> "...the Element is an Section 1.11.1.3."
Broken cross reference.

> "If specified that the value of the EBML Element MUST be within the defined range inclusively."
Either you meant to remove "that" or this is an incomplete sentence 
fragment.

> "See the Section 1.11.1.4..."
Delete "the".

> "A default value may be provided."
MAY? Is the existence of this attribute sufficient to provide it, or 
even if the attribute exists, is providing a default value something it 
merely MAY do?

> "If an Element is mandatory but not written within its Parent EBML Element, then the parser of the EBML Document MUST insert the defined default value of the Element."
What does it mean for an element to be mandatory? I think you mean 
minOccurs > 0, though that then raises the question of what it means if 
minOccurs > 1. Are parsers then meant to insert enough copies of the 
element set to the default value to make up for any and all missing 
occurrences?

Also, again, what is a parser? What does it mean for it to insert 
something? Where does it insert it?

> "As defined within the Section 1.8, the type MUST be set..."
Delete the first "the". Section 1.8 does not define that the type MUST 
be set to anything. I assume you mean that the section defines the 
content of the element for each type, but that's not what this sentence 
says.

> "The 'unknownsizeallowed' attribute only applies to Master-elements."
Does that mean it's legal for a non-Master Element to include an 
"unknownsizeallowed" in its schema, but someone validating a document 
with that schema is required to ignore it? Same question for the 
"recursive" attribute.

> "If the "maxver" attribute is not used it is assumed that the element has a maximum version equal to the value stored in the "version" attribute of ."
Broken cross-reference. Also, what does it mean for an attribute to be 
"used"? Is that like "expressed"? Or does it really just meant "present" 
again?

What is one expected to do if "maxver" is smaller than "minver"?

> "The '<element>' nodes shall contain..."
SHALL?

> "The '<documentation>' sub-element may use a 'lang' attribute which may be set to the RFC 5646 value of the language of the element's documentation."
MAY (two times)? I'm also allowed to set it to some other completely 
unrelated language? RFC 5646 should be a normative reference.

> "The '<documentation>' sub-element may use a 'type' attribute to distinguish the meaning of the documentation."
MAY?

> "Recommended values for the '<documentation>' sub-element's 'type' attribute include..."
RECOMMENDED? What do these values mean? Why not MUST? Can you describe 
reasons someone might reasonably choose to use other "type" attribute 
values?

> "An '<element>' node that defines an EBML Element which is a Child Element of another Parent Element MUST be stored as an immediate sub-element of the '<element>' node that defines the Parent Element."
Is it allowed to have two <element> nodes with the same Element ID as 
children of different Parent Elements? Is one simply expected to 
duplicate the whole contents of that <element> node under both parents? 
Are they allowed to have different attribute values for things like 
"level", "minOccurs", "maxOccurs", etc.? If so, what is the complete 
list of attributes that are allowed to differ?

= Identically Recurring Elements =

> "An Identically Recurring Element is an Element that may occur..."
MAY?

> "...and optimize the use of EBML in transmission."
What objective function is being optimized? How do Identically Recurrent 
Elements optimize it?

> "Identically Recurring Elements SHOULD include a CRC-32 Element as a Child Element..."
Why not MUST? Can you describe reasons someone might reasonably violate 
this?

This section is good for describing what someone is supposed to do if 
the Identically Recurring Elements are not, in fact, identical. Though, 
you may wish to point out in the Security Considerations that the 
extraneous copies or copies with an invalid CRC-32 Element are a 
potential side channel.

= Expression of range [sic] =

> "The 'range' attribute does not support date EBML Elements."
The definition of the range attribute said it could be used for Dates.

> "The 'range' expression may contain whitespace for readability but whitespace within a 'range' expression MUST NOT convey meaning."
How would whitespace within a 'range' expression convey meaning? I think 
this is a vague attempt to say _where_ whitespace is allowed, but as 
vague attempts go, it's pretty vague.

> "'x-y' where x and y are integers or floats and 'y' must be greater than "x", meaning that the value must be greater than or equal to 'x' and less than or equal to 'y'."
MUST (two times)? What is one supposed to do if 'y' is less than or 
equal to 'x'? Is there even any reason to forbid 'x' and 'y' from being 
the same?

> "'>x' where 'x' is an integer or float, meaning that the value MUST be greater than 'x'."
Earlier in the definition of the range attribute, you said something 
about "within the defined range inclusively", but this appears to define 
a range that excludes its end-point. So which is it, inclusive or 
exclusive? Is this meant to be treated as >=?

> "The 'range' may use the prefix 'not' to indicate that the expressed range is negated."
MAY? What does this do to the inclusivity rules?

> "Please also see the section on Section 1.11.1.5."
Delete "the section on".

> "...as defined in the C11 standard ISO/IEC 9899:2011 [6]..."
This should be a normative reference.

The discussion on hyphens also leaves out how the hyphen that separates 
the range is to be disambiguated from a signed (negative) float. Perhaps 
it's worth defining an EBNF grammar for this field?

= Note on the Use of default attributes to define [sic] Mandatory EBML 
Elements =

> "If a Mandatory EBML Element..."
This is the first time this term has appeared, at least in capitalized 
form. It appears here with no definition.

> "In this case, the default value of the Mandatory EBML Element may be assumed although the EBML Element is not present within its Parent EBML Element."
MAY? I'm allowed to not do any of that, also?

> "Also in this case the parser of the EBML Document MUST insert the defined default value of the Element."
Again, what is a parser? What does it mean to insert it? Where does it 
get inserted? Also, why say this again when you already said it? (with 
2119 language both times!) That's just a recipe for having it 
interpreted two different ways.

> "...than the EBML Element must be present as well."
You meant "then". MUST?

> "...then the EBML Element MUST be used."
What does it mean to be used? If the Element is an Identically Recurring 
Element, how do I satisfy this rule (which says I must use every such 
value) and also the rule that I only use the first one with a valid CRC 
(or failing that, just the first one)?

> "Is the Parent Element used?"
What does it mean to be used?

> "Then is storing the EBML Element required?"
REQUIRED?

The last two lines of this table are also identical to the preceding two.

= Note on the Use of default attributes to define [sic] non-Mandatory 
EBML Elements =

This section appears to simply be repeating something already said 
elsewhere.

= EBML Header Elements =

You've gone to a lot of trouble to define an XML schema for defining 
EBML elements, and then this section doesn't use it. Do you think it 
would be a good idea to at least have the table row names match the 
schema attribute names? (capitalization, "EBML ID" vs. "id", 
"Mandatory"/"Multiple" vs. "minOccurs"/"maxOccurs", etc.) Does the lack 
of a Mandatory attribute in the XML schema and the lack of a definition 
for "mandatory" in this document mean that only elements defined in this 
section and the next can ever be Mandatory? Should the specification of 
invalid values like "-" for Range and Default be taken to mean that 
those attributes should be treated as "not expressed" or is it also 
legal to include values like that in an EBML Schema?

> "Range       | 1"
Do I take this to mean that the _only_ valid values for EBMLVersion and 
EBMLReadVersion are 1? What is one expected to do if one encounters a 
different version number? E.g., what if EBMLReadVersion is 1 but 
EBMLVersion is 2?

> "The version of EBML parser used to create the EBML Document."
Why is a parser creating documents? This is why I ask what you might 
think is the obvious question, "What is a parser?"

Should there be a maximum values allowed for EBMLMaxIDLength and 
EBMLMaxSizeLength? How large of a value can an implementation put for 
these with a reasonable expectation that it will be supported?

= Global elements (used everywhere in the format) [sic] =

> "All Top-Level Elements of an EBML Document SHOULD include a CRC-32 Element as a Child Element."
Why not MUST? Can you describe reasons someone might reasonably violate 
this?

> "The CRC in use is the IEEE-CRC-32 algorithm as used in the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42..."
This should be cited as a normative reference.

Void elements should probably also be called out in the Security 
Considerations section as a possible side channel.