Subject: [Cellar] EBML Version/Read Version

From: Steve Lhomme <[email-masked]>
Date: Sun, 16 Oct 2016 14:57:26 +0200

So far there was no range defined for EBMLVersion and EBMLReadVersion.
The value 0 should be excluded. But I don't think excluding versions
other than 1 is good. There might be someday an EBML 2 version which
is backward compatible. That shouldn't make them invalid EBML 1
documents just because EBMLVersion is 2.

Here's a pull request to fix and clarify what the current value should be:
https://github.com/Matroska-Org/ebml-specification/pull/111

-- 
Steve Lhomme
Matroska association Chairman

---

From: Dave Rice <[email-masked]>
Date: Mon, 17 Oct 2016 21:07:17 -0400

> On Oct 16, 2016, at 8:57 AM, Steve Lhomme <[email-masked]> wrote:
> 

But if there is someday an EBML version 2, that would be because a new version of the EBML specification is defined. In a future EBML version 2 specification, I presume the range for EBMLVersion would be updated from `1` to `1-2`.

I suggest, per "EBML version 1 specification", that EBMLVersion=2 is considered invalid, since "EBML version 1 specification” won’t know what to expect.

Per "EBML version 2 specification”, both EBMLVersion=1 and EBMLVersion=2 are valid.

> https://github.com/Matroska-Org/ebml-specification/pull/111

I suppose I prefer not to accept this pull request. Why permit an EBML Writer to say EBMLVersion=2 or EBMLVersion=999, etc when such format is not even conceived or defined yet?
Dave

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 30 Oct 2016 08:15:28 +0100

> I suggest, per "EBML version 1 specification", that EBMLVersion=2 is considered invalid, since "EBML version 1 specification” won’t know what to expect.

There are 2 levels at play IMO. The validation level of a file that
could consider value 2 is OK as long as EBMLReadVersion is 1. And
there is the semantic level that would say that the reader doesn't
know of any EBML version 2. But IMO as long as EBMLReadVersion is 1,
it doesn't matter what the EBMLVersion says, the file will be
parseable by a reader that can handle EBML version 1. So at the very
least I think EBMLVersion should be let free (not 0). I will not have
any impact on validity or paseability (?).

The question remains for EBMLReadVersion. I think forcing 1 for now is
OK. It's like a reserved bit that must always be 0. If it's not 0 you
know the bistream is either wrong or there's something you don't know
about. And that's what EBMLReadVersion is for. I'll update my pull
request.