Subject: [Cellar] WGLC draft-ietf-cellar-matroska --- status of this document

From: Martijn van Beurden <[email-masked]>
Date: Thu, 7 Apr 2022 20:27:41 +0200

Hi all,

Under 2, Status of this document, it says
> Note that versions 1, 2, and 3 have been finalized. Version 4 is currently work in progress. There MAY be further additions to v4.

This brings up the question, which version of Matroska is defined by
the document? I guess all of them, but perhaps this should be stated
clearly? Also, it seems strange to base a standards track RFC on a
work in progress?

Kind regards,

Martijn van Beurden

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2022 19:50:12 -0400

Martijn van Beurden <[email-masked]> wrote:
    >> Note that versions 1, 2, and 3 have been finalized. Version 4 is
    >> currently work in progress. There MAY be further additions to v4.

I think version 3, same as flac.

    > clearly? Also, it seems strange to base a standards track RFC on a work
    > in progress?

There will be normative references from Matroska to ffv1-v3, RFC9043.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jerome Martinez <[email-masked]>
Date: Sat, 9 Apr 2022 02:10:32 +0200

> I think version 3, same as flac.

Issue there is that Matroska v4 brings new stuff good to have in the 
standard.
There is no version upgrade until there is a breaking change, that means 
that v4 is stable there, and that there MAY be additions, and theses 
additions will not break the v4 standard, like a minor version.
Note that this is same for FFV1, FFV1 version 3 has a micro_version 
number (currently 4, numbers 0-3 are reserved for past use) and in the 
future there may be a micro_version 5 which would add new info 
compatible with decoders not aware of the new features.
Actually also like HTTP, version 1 got lot of updates and browsers are 
expected to skip the new HTTP headers, that does not mean that HTTP 1 
should not have been standardized a long time ago.

IMO Matroska standard should include version 4, knowing that version 4 
may receive updates in the future.
Suggestion of wording:

***
Note that versions 1, 2 and 3 are no more maintained, no new elements 
are expected in files with theses version numbers.
Version 4 is the current version, and new elements are expected to be 
defined in the future.
For all versions, a software reading files with unknown elements SHOULD 
ignore them.
***

This would permit a version "4.1" (or "version 4 extension X, or 
whatever else for the naming :) ) compatible with version 4 in the future.

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Fri, 15 Apr 2022 15:34:24 +0200

On 2022-04-09 2:10, Jerome Martinez wrote:
>>      > Under 2, Status of this document, it says
>>      >> Note that versions 1, 2, and 3 have been finalized. Version 4 is
>>      >> currently work in progress. There MAY be further additions to v4.
>>

Actually it's Matroska 1 to 4 (current).

> additions will not break the v4 standard, like a minor version.

There is no minor version in Matroska (or EBML) nor "breaking changes" 
as additions should be backward compatible. Otherwise it's a derivative 
of Matroska (kind of like WebM which almost had issues with RAP).

IMO version 5 is anything that comes after Matroska has its own RFC. 
There are a few things already lined up:
https://github.com/ietf-wg-cellar/matroska-specification/pulls?q=is%3Apr+is%3Aopen+label%3Amatroska-v5
https://github.com/ietf-wg-cellar/matroska-specification/issues?q=is%3Aissue+is%3Aopen+label%3Amatroska-v5

> For all versions, a software reading files with unknown elements SHOULD 

https://github.com/ietf-wg-cellar/matroska-specification/pull/588

Took some of your text but kept the unknown elements part out. IMO it 
belongs in the EBML section.

> whatever else for the naming :) ) compatible with version 4 in the future.

Nope, the are only integer version of Matroska. I'm not even sure adding 
new values to an enum would qualify to go in version 4.

So far the versioning has been fluid as developers would just support 
elements they find in the wild (wild web) and not care about the 
version. Given all files are backward compatible players don't actually 
have to check the version.

> Jérôme
> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar