Matroska Media Container Format Specifications
draft-ietf-cellar-matroska-21

[Ballot comment]
Thanks for your work on this document, and I apologize for the length of time it's taken me to review the changes. I have a couple of final comments.

1. Thanks for the "Updates to RFC 8794" section! I think you also should add the "Updates" header. I expect this was just an oversight since you've gotten the rest of the formalities right including mentioning the update in the abstract.

2. I notice you haven't changed the language of the form "are set to 00". I think you asked me about this in an email reply a long time ago and I dropped the ball. Indeed, my suggestion was to use "0b00" instead of "00" (and similar, wherever you are writing out binary, whatever the specific values). That is, I think you should do as other RFCs do and follow the usual C syntax for number representation. As you've written it, with a leading zero and no base indicator, the casual reader might suppose you were using octal, same for "set to 01". Similarly, "are set to 11" looks to my eye as if it meant "are set to (decimal) eleven". Of course, with just a tiny bit of effort, your true meaning can be inferred from "the bits 5-6..." but why not specify the radix?

[Ballot discuss]
(Updated ballot per -18)

[Per -16]
> ** Section 5.1.4.1.31.9.  Table 26.  ContentEncAlgo Element.  Several insecure
> algorithms are suggested as options (e.g., DES, 3DES).  Please add guidance
> that:
>
> -- Mastroska Writers MUST NOT use insecure ciphers (e.g., DES, 3DES) to create
> "new content" (not sure of the appropriate word) either in this section or in
> the Security Considerations
>
> -- Add cautionary text that these algorithms are not secure

[Per -18]
Thanks for adding the additional text into Table 26 – specifically, “[t]his value SHOULD be avoided” for DES, 3DES, and Blowfish.  This clarifying text begs clarity on when these could still be used.

There was a proposal on the mailing list for language against all use of encrypted block --
https://mailarchive.ietf.org/arch/msg/cellar/CUXVLzNzSzGpz5GLro9f6BcpQQc/.  Should this be done?

I proposed clarifying language against -16 to adopt an OpenPGP refresh (draft-ietf-openpgp-crypto-refresh) approach which distinguishes between disallowing the use of insecure ciphers for Writers, but allowing for the reading/processing archives previously made with these historic algorithms (that might have been appropriate at the time of creation). 

NEW
Mastroska Writers MUST NOT use insecure cryptographic algorithms to create new archives or streams, but Mastroska Readers MAY support these algorithms to read previously made archives or stream.

[Per -16]
> ** Section 14
>
> ==[ snip ]==
> This document does not specify any kind of standard for encrypting elements.
> The issue of key scheduling, authorisation, and authentication are out of
> scope. External entities have used these elements in proprietary ways. ==[ snip
> ]==
>
> Based on this text, it isn’t clear if Mastroska security properties are
> supposed be interoperable solution for encrypted content across applications
> (and how much is out of scope/left to proprietary implementations).  If
> interoperability is not expected, please add language to that effect.  Some of
> the feedback below might not be applicable if interoperability isn’t expected.

[Per -18] My position continues to be that strong language is needed to explain Section 14.

OLD
  Encryption in Matroska is designed in a very generic style to allow
  people to implement whatever form of encryption is best for them.  It
  is possible to use the encryption framework in Matroska as a type of
  DRM (Digital Rights Management).

  This document does not specify any kind of standard for encrypting
  elements.  The issue of key scheduling, authorisation, and
  authentication are out of scope.  External entities have used these
  elements in proprietary ways.

NEW

This Matroska specification provides no interoperable solution for securing the data container with any assurances of confidentiality, integrity, authenticity, or to provide authorization.  The ContentEncryption Element (Section 5.1.4.1.31.8) and associated sub-fields (Section 5.1.4.1.31.9 – 12) are defined only for the benefit of implementers to construct their own propriety solution or as the basis for further standardization activities.  How to use these fields to secure a Matroska data container is out of scope.  As are any related issues such as key management and distribution.

Matroska Readers who encounter containers that use the fields defined in this section MUST rely on out-of-scope guidance to decode the associated content.

OLD

  The AES-CTR system, which corresponds to ContentEncAlgo = 5
  (Section 5.1.4.1.31.9) and AESSettingsCipherMode = 1
  (Section 5.1.4.1.31.12), is defined in the [WebM-Enc] document.

NEW

An example of an extension that builds upon these security-related fields in this specification is [WebM-Enc].  It uses AES-CTR, ContentEncAlgo = 5 (Section 5.1.4.1.31.9) and AESSettingsCipherMode = 1 (Section 5.1.4.1.31.12).

Additionally, please add caution to the Security Considerations to the effect of:

NEW

The Matroska specification provides no security assurances for the data container.  Fields related to adding security properties to the container described in Sections 5.1.4.1.31.8 – 12 do not form the basis of an interoperable solution.  Any implementation which builds on top of these fields will need to fully define their use and consider the security implications of the resulting design.

> ** Section 5.1.4.1.31.*.  AES and associated modes (CTR and CBC) are named.
> What is the key size?  Is it AES-128 (?) or -256. [WebM-Enc] references in
> Section 14 suggests it is 128.  Please be explicit.

Please explicitly say that some of the algorithms described in Table 26 support different modes of operations and key sizes.  The specification of these parameters is required for a complete solution, but is out of scope of this document and left to the propriety implementations using them or subsequent profiles of this document.

[Per -16]
> ** Section 5.1.4.1.31.10.  ContentEncKeyID Element.
>      definition:  For public key algorithms this is the ID of the public
>      key the the data was encrypted with.
>
> The descriptive text is suggesting that the ID to a public key if public key
> algorithms are described.  However, Table 26 only lists symmetric algorithms.
> How is this key ID used?

I didn’t receive a response to this feedback.  Even recognizing that the security solution is out-of-scope, this text is inconsistent with existing text as described above.  Is the public key solution a KEK?

There is related text in Section 14 which references public keys which should be harmonized.  Specifically:

  For encryption systems sharing public/private keys, the creation of
  the keys and the exchange of keys are not covered by this document.
  They have to be handled by the system using Matroska.

[per -16]
> ** Section 14.
>    Encryption in Matroska is designed in a very generic style to allow
>    people to implement whatever form of encryption is best for them.  It
>    is possible to use the encryption framework in Matroska as a type of
>    DRM (Digital Rights Management).
>
> Enabling flexibility makes sense.  How is algorithm agility enabled?  How would
> a new algorithm be added to Table 26?  In a protocol context, this might be
> handled by an IANA registry enabling extensibility.

[per -18]
I proposed removing this specific text above.  However, my original questions stands.  How is agility enabled?  Can a proprietary implementation insert a new code point? 

[per -16]
> ** Please add cautionary language in the Security Considerations about what
> explicitly would NOT be covered even if encryption was used.  For example,
> Section 16 of RFC8794 notes that:
>
> ==[ snip ]==
> Even if the semantic layer offers any kind of encryption, EBML itself could
> leak information at both the semantic layer (as declared via the DocType
> Element) and within the EBML structure (the presence of EBML Elements can
> be
> derived even with an unknown semantic layer using a heuristic approach -- not
> without errors, of course, but with a certain degree of confidence). ==[ snip
> ]==
>
> What are the specifics here on what “leaks”?

I didn’t see a response to this issue.

[Ballot comment]
Thank you for documenting this important format in the IETF.

Thanks for addressing my COMMENT feedback and explaining the Matroska design to address some of my DISCUSS feedback.

[Ballot comment]
Thanks for addressing my discuss points.

Copying the discuss points below -
======================================================================================================================
However, I have two observation/questions that I would like to discuss to have clear opinions and better understanding.

    - Top-Level Elements are optional fields in the segment. While segment is a MUST part in the container but segments values (elements) are MAY, this to me says one can just put a dummy segment in the container and it will be fine. is that correct interpretation? however, there is a RECOMMENDED segment element, so how should we interpret the statement that Top-level Elements are all MAY? 

    - Even if the Top-Level Elements MAY be available in the container, some of the elements has MUST parts when they are present. However, I have not notices description of the consequences or error handling is those MUST parts are not available in the elements. I wonder what would be the course of action if the MUST parts of a certain element is not there. In general, I was expecting error handling in this specification which is not there and would like to discuss the reasoning behind it.

[Ballot comment]
# GEN AD review of draft-ietf-cellar-matroska-16

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/l2gsKdSbRBtCBNMrVZBmmRiu1IM).

## Comments

### Note to self

Check whether Expert Review is an appropriate registration policy here.

### DOWNREFs

Possible DOWNREF from this Standards Track doc to `[Twofish]`. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to `[Blowfish]`. If so, the IESG
needs to approve it.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms `mastertrackuid`, `masteringmetadata`, `mastering`,
  `mastertrackseguid`, and `master`; alternatives might be `active`,
  `central`, `initiator`, `leader`, `main`, `orchestrator`, `parent`,
  `primary`, `server`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`
* Term `blindly`; alternatives might be `visually impaired`, `unmindful of`,
  `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
  `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Duplicate references

Duplicate normative references to:
`https://csrc.nist.gov/publications/detail/fips/197/final`.

### Outdated references

Document references `draft-ietf-cellar-tags-09`, but `-10` is the latest
available revision.

Document references `draft-ietf-cellar-codec-09`, but `-10` is the latest
available revision.

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://web.archive.org/web/20110214132246/http://labs.divx.com/node/16602
* http://web.archive.org/web/20101222001148/http://labs.divx.com/node/16601
* http://web.archive.org/web/20160609214806/https://www.fourcc.org/yuv.php
* http://web.archive.org/web/20160609214806/https://www.fourcc.org/rgb.php

### Grammar/style

#### Section 3, paragraph 3
```
ch should have been used instead. Therefore Matroska writers MUST NOT use EBM
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 4.4, paragraph 33
```
--------+ Figure 9: Representation of a Attachments Element. The Tags Element
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 5.1.4.1.29.2, paragraph 3
```
s this is the ID of the public key the the data was encrypted with. stream c
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.1.4.1.31.6, paragraph 5
```
g ID to identify the Chapter. For example it is used as the storage for [Web
                                  ^^^^^^^
```
A comma is probably missing here.

#### Section 5.1.7.1.4.11, paragraph 1
```
SHOULD include a CRC-32 Element as a their first Child Element. The Segment
                                  ^^^^^^^
```
A determiner cannot be combined with a possessive pronoun. Did you mean simply
"a" or "their"?

#### Section 5.1.8.1.1.3, paragraph 1
```
yframe flag and Discardable flag. Otherwise everything is the same. Bit 0 is
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 6, paragraph 1
```
er flags are set to 00. The Block for a 800 octets frame is as follows: +====
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 10.4.2, paragraph 8
```
multiplied Block Timestamp is a floating values in nanoseconds. The Matroska
                              ^^^^^^^^^^^^^^^^^
```
The plural noun "values" cannot be used with the article "a". Did you mean "a
floating value"?

#### Section 10.4.2, paragraph 8
```
-2 form [ISO639-2] (like "fre" for french), or such a language code followed
                                  ^^^^^^
```
"French" needs to be capitalized when you are referring to the language or
country.

#### Section 10.4.4, paragraph 1
```
image SHOULD be presented with a 90 degree counter-clockwise rotation, with
                                  ^^^^^^^^^
```
When "90-degree" is used as a modifier, it is usually spelled with a hyphen.

#### Section 11.1.1, paragraph 3
```
ding to the cumulative duration of the the previous Ordered Chapters. As an
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 11.3, paragraph 2
```
ack with a UID and all its flags. However the codec ID is meaningless becaus
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 12, paragraph 2
```
red in the same channel as the track its linked to. When content is found in
                                    ^^^
```
Did you mean "it's" (contraction of "it is/has")?

#### Section 16.2, paragraph 2
```
during the film, which is an unusual specialized audio service that Matroska
                            ^^^^^^^^^^^^^^^^^^^
```
Make sure that the adjective "unusual" is correct. Possibly, it should be an
adverb (typically ~ly) that modifies "specialized". Possibly, it should be the
first word in a compound adjective (hyphenated adjective). Possibly, it is
correct.

#### Section 17, paragraph 1
```
udio tracks and finds that multiple seem equally and maximally preferable, i
                                    ^^^^
```
The verb "seem" is plural. Did you mean: "seems"? Did you use a verb instead of
a noun?

#### Section 17.2.1, paragraph 2
```
only found in ordered chapters Furthermore there are other EBML Elements wh
                                ^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Furthermore".

#### Section 18.8, paragraph 2
```
ChapterFlagHidden flag works independently from parent chapters. A Nested Ch
                              ^^^^^^^^^^^^^^^^^^
```
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

#### Section 19.2, paragraph 9
```
d.(jpg|png). The filenames are case sensitive. The following table provides
                              ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 20.1.2, paragraph 1
```
on. This Font Name can be different than the Attachment's FileName, even when
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style.

#### Section 20.1.2, paragraph 6
```
nts were used in existing files. Therefore it is RECOMMENDED for a Matroska
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 20.1.3, paragraph 1
```
e file extension check MUST be case insensitive. Matroska writers SHOULD use
                              ^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 20.2.2, paragraph 3
```
e stream has neither a SeekHead list or a Cues list at the beginning of the
                                    ^^
```
Use "nor" with neither.

#### Section 20.3, paragraph 2
```
s Void Element should be adjusted depending whether the Matroska file already
                                  ^^^^^^^^^
```
The verb "depend" requires the preposition "on" (or "upon").

#### Section 20.4, paragraph 2
```
fore all the locations are known. Therefore shis layout is rarely used. * Se
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".
Also, shis -> this?

#### Section 20.4, paragraph 2
```
a Reader could include: * Storage of a arbitrary and potentially executable d
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 20.5.1, paragraph 3
```
be allocated according to the "First Come First Served" policy [RFC8126]. The
                                    ^^^^
```
It seems that a comma is missing.

#### Section 27.1, paragraph 12
```
be allocated according to the "First Come First Served" policy [RFC8126]. Cha
                                    ^^^^
```
It seems that a comma is missing.

#### Section 27.1, paragraph 12
```
erTrackUID and MasterTrackSegUID should must be present and BlockGroups for t
                                ^^^^^^^^^^^
```
Two modal verbs in a row. Did you mean: "should, must", "should" or "must"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
support the DISCUSSes of Roman and John.

Specifically, I agree with Roman that defining DES and Blowfish
is a problem. Both of these are basically the equivalent of "not
encrypted". DES is easily brute forced, and blowfish is vulnerable to
birthday attacks due to its limited key size, see https://sweet32.info/
Perhaps a "usage_note" can be added here that discourages the use of
DES, 3DES and Blowfish. (3DES isn't broken but it is an order of magnitude
harder on the CPU that AES). Or perhaps the usage_note can say that
encrypted streams with ContentEncAlgo of DES,3DES and Blowfish MUST NOT
be used to generate content, and are only defined to allow decrypting
of previously generated content.

I do not understand the content of ContentEncAESSettings ? Which settings
are possible?

For AESSettingsCipherMode, is there a reason not to support an AEAD such
as AES-GCM or POLYCHACHA ?  For AES-CTR and AES-CBC, I would expect some
guidance on integrity checking. Eg does one use AES-CBC with SHA1/SHA256
for integrity? Or is it considered that all maliciously modifying a stream
can at most cause decrypting into garbage which will be handled properly
by the application anyway?

        Storage of a arbitrary and potentially executable data within an
        Attachment Element. Matroska Readers that extract or use data
        from Matroska Attachments SHOULD check that the data adheres
        to expectations.

Why is this a SHOULD and not a MUST. Especially since "adheres to
expectations" is already vague to leave wiggle room.

[Ballot comment]
A number of MUST/MUST NOT appear in the text. What should happen if those
are violated? It is not always clear to me from context. Should there be
some generic text that says "stop attempting to read more data and abort"
along with some possible "ignore if violated" uses?



        The next ContentEncoding (next ContentEncodingOrder. Either the
        data inside ContentCompression and/or ContentEncryption).This
        value SHOULD NOT be used as it's not supported by players.

Why define a value if it SHOULD NOT be used? It would be better to not define it.
Alternatively, this could have another "usage_note" like some other values have
and it could state why it is not recommended for use?

        22.1. Recommendations
        The following recommendations are provided to optimize Matroska performance.

Perhaps add that if encryption is required, that AES should be used and not
3DES as 3DES performs very poorly.

[Ballot comment]
I like Warren am balloting no objection on the basis that this is way outside of my area of expertise.  I did read 80% of the document though!

[Ballot discuss]
** Section 5.1.4.1.31.9.  Table 26.  ContentEncAlgo Element.  Several insecure algorithms are suggested as options (e.g., DES, 3DES).  Please add guidance that:

-- Mastroska Writers MUST NOT use insecure ciphers (e.g., DES, 3DES) to create "new content" (not sure of the appropriate word) either in this section or in the Security Considerations

-- Add cautionary text that these algorithms are not secure

** Section 14

==[ snip ]==
This document does not specify any kind of standard for encrypting elements. The issue of key scheduling, authorisation, and authentication are out of scope. External entities have used these elements in proprietary ways.
==[ snip ]==

Based on this text, it isn’t clear if Mastroska security properties are supposed be interoperable solution for encrypted content across applications (and how much is out of scope/left to proprietary implementations).  If interoperability is not expected, please add language to that effect.  Some of the feedback below might not be applicable if interoperability isn’t expected.

** Section 5.1.4.1.31.*.  AES and associated modes (CTR and CBC) are named.  What is the key size?  Is it AES-128 (?) or -256. [WebM-Enc] references in Section 14 suggests it is 128.  Please be explicit.

** Section 5.1.4.1.31.10.  ContentEncKeyID Element.
    definition:  For public key algorithms this is the ID of the public
      key the the data was encrypted with.

The descriptive text is suggesting that the ID to a public key if public key algorithms are described.  However, Table 26 only lists symmetric algorithms.  How is this key ID used?

** Section 5.1.4.1.31.12.  In AES CTR and CBC modes typically, an IV is also passed in the encryption and description algorithm.  How is that handled for description in an interoperable way?  Section 14 references [WebM-Enc] which suggest that the IV is stored in the block.

** Section 14.
  Encryption in Matroska is designed in a very generic style to allow
  people to implement whatever form of encryption is best for them.  It
  is possible to use the encryption framework in Matroska as a type of
  DRM (Digital Rights Management).

Enabling flexibility makes sense.  How is algorithm agility enabled?  How would a new algorithm be added to Table 26?  In a protocol context, this might be handled by an IANA registry enabling extensibility.

** Section 14.  This section seems to be missing basic caution on using AES-CTR and AES-CBC such as:

-- For AES-CTR, IVs cannot be reused for a given key (see Section 7 of [RFC3686] describing it in the IPsec context)

-- It is best to use AES-CTR and CBC with an integrity mechanism, and the consequences if it is not.

** Please add cautionary language in the Security Considerations about what explicitly would NOT be covered even if encryption was used.  For example, Section 16 of RFC8794 notes that:

==[ snip ]==
Even if the semantic layer offers any kind of encryption, EBML itself could leak information at both the semantic layer (as declared via the DocType Element) and within the EBML structure (the presence of EBML Elements can be derived even with an unknown semantic layer using a heuristic approach -- not without errors, of course, but with a certain degree of confidence).
==[ snip ]==

What are the specifics here on what “leaks”?

[Ballot comment]
Thank you for documenting this important format in the IETF.

** Section 2.
  No
  new elements are expected in files with version numbers 1, 2, or 3.

Is this the same thing as saying “no elements will appear in version 1 – 3 that is not documented here?”  If so, please make it clearer.

** Values from ISO/IEC 23001-8:2016 or ITU-T H.273 are cited in Tables 14, 18, and 19.  This (H.273) needs to be a normative reference.

** Section 5.1.4.1.31.3. ContentEncodingScope Element.  What does it mean for the scope to be private (value = 2). What is “the track’s private data”?

** Section 21.1.  Please a normative reference for JPEG and PNG.

** Section 23.1.
  File access can simply be reading a file located on your computer,
  but also includes accessing a file from an HTTP (web) server or CIFS
  (Windows share) server.  These protocols are usually safe from
  reading errors and seeking in the stream is possible.  However, when
  a file is stored far away or on a slow server, seeking can be an
  expensive operation and should be avoided.

Can the assurance that HTTP server is “usual safe … to seek” given that it could be deployed “far away” or on a “slow server”?

** Section 26. 
-- Borrowing from the Security Considerations in various codec documents (RFC9043 and RFC6386).  Consider adding:

NEW
Matroska Reader implementations need to be robust against malicious payloads.  Those related to denial of service are outlined in Section 2.1 of [RFC4732].  Although rarer, the same may apply to a Matroska Writer.  Malicious stream data must not cause the Writer to misbehave, as this might allow an attacker access to transcoding gateways

-- Also adding a reminder that there will be additional formats inside.  Consider adding:

NEW
As an audio and visual container format, a Matroska file or stream will potentially encapsulated numerous byte streams created with a variety of codecs.  Implementers will need to consider the security considerations of these encapsulated formats.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-cellar-matroska-16
CC @jgscudder

## DISCUSS

(This is another, and I hope the final, update to my ballot. I add one more DISCUSS point, directly following, and I add COMMENTs and NITs, starting with Section 15.1. I apologize for the episodic nature of this review, and hope it was helpful to get the early part.)

### MatroskaTags reference

I notice that the [MatroskaTags] document is referenced in several places. At first glance, it seems like this is a document that "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work" [1], in which case it should be Normative.

I can see why the WG would be hesitant to make the reference Normative, since the document seems to be less mature and might hold up RFC publication for some time while it also progresses. But please be sure that it really does fit the criteria of "only [providing] additional information", and that the current spec can stand alone without it.

Because I don't have the subject area expertise to make this call with confidence, I don't intend to hold a DISCUSS on this point past the telechat, this is primarily here to ensure that the question is considered by others.

[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

--

(This is an update to my previous ballot, to add one more question. The original ballot (below) was entirely questions for the authors (though of course, anyone is welcome to engage). The new question is primarily process-related and I'm adding it mostly to flag the issue for the sponsoring AD, and to make sure we cover it during IESG discussion, although again, anyone is welcome to engage.)

### Conflict with RFC 8794, potentially resolved by errata

Primarily for the AD/IESG: I happened to notice that there are 9 errata open against RFC 8794, the EMBL spec, which is a normative reference for this doc. All of them are in "reported" state so have no normative force right now. Two of them (ID 7189 and ID 7191) are added specifically to bring Matroska's usage into compliance (or rather, to redefine "compliance" to include what Matroska does).

It's not clear to me that these are proper uses of the errata process, but it's not my WG or area. In any case, it seems like this is a hint that there's a potential problem. Whether the problem should be fixed by verifying the errata, or some other way, I don't know.

Primarily for the authors:

(Update: thanks for your replies to this part, your proposed solutions sound good to me.)

Thanks for this document. It's well outside my comfort zone (I'm a routing protocols guy) and I appreciate the effort that's gone into making what is clearly a major piece of work accessible to someone like me.

Although I haven't completed my review, as I've gone through it I found two sections that seemed worth having a DISCUSSion about. Since the Section 10 DISCUSSion might take a while, I figured I should raise it now rather than wait to finish my entire review. So, I may add some additional comments later.

### Section 6.8

To quote §6.8 in its entirety:

  The Tags Element is most subject to changes after the file was
  originally created.  For easier editing, the Tags Element SHOULD be
  placed at the end of the Segment Element, even after the Attachments
  Element.  On the other hand, it is inconvenient to have to seek in
  the Segment for tags, especially for network streams.  So it's better
  if the Tags Element is found early in the stream.  When editing the
  Tags Element, the original Tags Element at the beginning can be
  overwritten with a Void Element and a new Tags Element written at the
  end of the Segment Element.  The file size will only marginally
  change.

I've read this several times and I just can't figure out how to reconcile "the Tags Element SHOULD be placed at the end of the Segment Element" with "it's better if the Tags Element is found early in the stream". Have I missed some subtlety in the distinction between "the Segment Element" and "the stream"? Or are you setting up a dichotomy on purpose? Or something else?

My guess is you're purposefully setting up a dichotomy (the Tags Element both should go early, and late) and then proposing a solution for it (put it early, but if it gets revised, Void it out and put the replacement late). Is that it? If so, I'd recommend rewriting to be clearer about what you're doing and not presenting the reader with a contradiction. Absent a significant rewrite, at a minimum the SHOULD has to go.

### Section 10

It seems as though there are significant unstated assumptions in the descriptions throughout this section and its subsections. I'll go into further detail on specifics below. Since the Block is such a fundamental structure for this document, it seems worth putting in some extra effort to make sure its description is clear.

In routing protocol specifications we tend to use quaint ASCII protocol packet diagrams with bit rulers along the top. Your use of variable-length fields makes this approach difficult, but I regretted not having some kind of graphical representation to reference, which might otherwise have helped. $0.02.

### Throughout, "bits" representation

In various places, you have language like "The bits 5-6 of the Block Header flags are set to 11" and similar. This language seems like it needs to be fixed, because the simplest plain English reading of the sentence (IMO anyway) is "bit 5 is set to decimal 11, and so is bit 6", which doesn't make sense. The most straightforward fix would be to write "... is set to 0b11" to indicate that you're writing the value in binary.

### Tables 36 and following, semantics

The semantics of the tables are not clear to me, and I don't see that they're defined anywhere:

Offset: What is this? All the examples are a small hex value and a plus sign. The plus sign generally means "or more" colloquially, although if this were a regex it would mean something about repetition. In any case, I don't know WHAT it means here. By the way, why are you showing these in hex and not decimal representation?

Player: This says "MUST" sometimes and is a hyphen other times. What does this mean? That a compliant Matroska Player MUST implement support for certain things (the MUSTs) and... something something I can't guess, for other things (the hyphens)?

### Section 10.1, Track Number

The first line of Table 36 description is "Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc.) (most significant bits set to increase the range)."

First, a suggestion: if you're saying "encoded as an EBML VINT" (which I think is what you mean) then say so, with xref, since that's a well-defined format with a well-defined reference. Second, a concern: since you're using a variable-length encoding here, I don't get how you can provide a specific offset for the later fields; Timestamp's location is presumably "after Track Number". Maybe that's what the "0x01+" notation means? It's telling me that Timestamp won't be any earlier than byte 1, but it might be later, depending on how Track Number is coded? But if the + means "or later" I don't see how Track Number gets 0x00+ -- what would make it start later than byte 0?

### Tables 40 and following, semantics

The various lacings have tables with a column headed "block octets" or "block octet". Given that the header is variable-length (because of the Track Number encoding) I don't see how these block octets can be known a priori. I guess perhaps the answer is "this is just an example, in a case where the Track Number happens to be encoded in a single byte, so the header occupies octets 0-3". If that is the case, I suggest stating it explicitly, perhaps in the introductory text of §10.4.

### 10.4.2 Xiph lacing, description of encoding

After looking at the example (thank you for providing this) and checking RFC 3533, I see what the coding is, but I think the description needs some work. Here's what I understand your intent to be, with some comments:

"Lacing Head on 1 Octet". I'm not able to make sense of these words, on their own. I infer from the examples that what you mean is, the first octet of the block data is a single unsigned integer that provides the number of frames in the lace minus one, meaning a lace can contain between 1 and 256 frames. Is that right?

Then that's followed by a series of integers, described as "Lacing size of each frame except the last one". These indicate the sizes of the respective lace frames other than the final one (which is inferred). If the number of frames in the lace is N, there will be N-1 integers in the list. The integers are variable-sized, and the encoding of an integer is a repetition of zero or more octets with value 255, followed by a single octet with a value less than 255. The frame size value is the sum of the octet values.

If my paragraph above is a correct description, I think your paragraph that begins "The lacing size is split into 255 values" needs work. To begin with, the plain English reading of "is split into 255 values" is "it's split into 255 distinct things", which is not what you mean.

(Update: thanks for explaining why this point was mistaken.  By the way, what happens if N=1? I appreciate that it would be silly to use anything other than the "no lacing" option in this case, but is it forbidden to encode a single frame in one of the other lacings? Given there's no way to properly do the encoding, it seems like it might be worth saying explicitly that this is a MUST NOT.)

### 10.4.3 EBML lacing, encodings

The previous point about "on 1 Octet" applies.

In this case, I have no problem with the integer coding definition, it's clear. But the example gave me difficulty in several ways.

In the second line of Table 43, you have

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame
(800 = 0x320 + 0x4000)

My first attempt at understanding how eight hundred can be equal to 0x320 + 0x4000 was a fail, because of course using the normal understanding of the "=" and "+" symbols, it can't be. My second attempt was to interpret this as saying that you're using the VINT coding, and the "=" is just (confusingly) being used to mean the colloquial English, i.e. you're saying "800, encoded in VINT as 0x4 for the VINT_WIDTH and VINT_MARKER, meaning it's two octets wide, followed by 0x0320 for the next 14 bits... and 0x320 is decimal 800."

Looking at the third line,

Block Octets Value Description

7-8 0x5e 0xd3 Size of the second frame
(500 - 800 = -300 = -0x12c + 0x1fff + 0x4000)

Once again I think the descriptive text is confusing: the size of the second frame isn't -300, though I do get that you store -300 to let the size of the second frame be computed, as 800 - 300, to give 500, which is indeed the size.

Second, "-0x12c" isn't any standard notation I'm aware of. I get that you're using it to mean "negative 300". Then 0x1fff is the hex value for (2^((7*2)-1)-1), and the addition of 0x4000 is the value for VINT_WIDTH and VINT_MARKER for a 2-octet encoding. At a minimum, I would rewrite this as "0x1fff + 0x4000 - 0x012c" to eliminate the negation sign and produce an expression that would parse, but read on.

It seems to me that readability would benefit from dividing the examples up -- a subsection on VINT/S_VINT, and a subsection on the actual Block encoding. For example, the VINT part could go something like this, inserted directly after Table 42.

  In our example, we will need to be able to represent 800, the size of
  the first frame, as a VINT. This is done using a 2 octet wide VINT as
  0x4000 + 0x0320 -- the 0x4000 is the VINT_WIDTH and VINT_MARKER, and
  the 0x0320 is the hexadecimal representation of decimal 800. The
  resulting VINT representation is 0x4320. We will also need to be able
  to represent -300, the offset required for the size of the second
  frame, as a signed VINT. This is done as 0x4000 + 0x1fff - 0x012c. In
  this expression, 0x4000 is again the VINT_WIDTH and VINT_MARKER,
  0x1fff is the hexadecimal representation of (2^((7*n)-1) - 1) for n
  of 2, and 0x012c is the hexadecimal representation of 300. The
  resulting signed VINT representation is 0x5ed3.
 
Or instead of talking about 300, you could also talk about "500 - 800", making the expression "0x4000 + 0x1fff + (0x01f4 - 0x0320)", and/or you could represent each value in the most convenient radix for clarity, as in "0x4000 + 0x1fff + (500 - 800)".
 
Then maybe you'd rewrite the descriptions in Table 43 something like

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame, 800,
encoded as a VINT

7-8 0x5e 0xd3 Offset between size of first
frame and size of second frame,
encoded as a signed VINT. To
recover the size of the second
frame, we sum this value with
the preceding frame, so,
(-300) + 800 = 500.

### 10.5, misuse of RFC 2119 keywords

  When a frame in a BlockGroup is not a RAP, all references SHOULD be
  listed as a ReferenceBlock, at least some of them,

Which is it? All? Or some of them? The RFC 2119 SHOULD is confused about what it needs to do here. Even if you remove the keyword (for example rewriting as "should"), if I were implementing this I'd have a hard time knowing what you're asking me to do.

                                                      even if not
  accurate, or one ReferenceBlock with the value "0" corresponding to a
  self or unknown reference.  The lack of ReferenceBlock would mean
  such a frame is a RAP and seeking on that frame that actually depends
  on other frames MAY create bogus output or even crash.

The RFC 2119 MAY is wrong in this context, you seem to be using it to express "might". As written, a strict reading would mean you're saying "it is explicitly OK, though optional, if implementations decide to create bogus output or crash in this case". You can fix this by replacing the MAY with "might" or "could".

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-cellar-matroska-16
CC @jgscudder

## DISCUSS

(This is another, and I hope the final, update to my ballot. I add one more DISCUSS point, directly following, and I add COMMENTs and NITs, starting with Section 15.1. I apologize for the episodic nature of this review, and hope it was helpful to get the early part.)

### MatroskaTags reference

I notice that the [MatroskaTags] document is referenced in several places. At first glance, it seems like this is a document that "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work" [1], in which case it should be Normative.

I can see why the WG would be hesitant to make the reference Normative, since the document seems to be less mature and might hold up RFC publication for some time while it also progresses. But please be sure that it really does fit the criteria of "only [providing] additional information", and that the current spec can stand alone without it.

Because I don't have the subject area expertise to make this call with confidence, I don't intend to hold a DISCUSS on this point past the telechat, this is primarily here to ensure that the question is considered by others.

[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

--

(This is an update to my previous ballot, to add one more question. The original ballot (below) was entirely questions for the authors (though of course, anyone is welcome to engage). The new question is primarily process-related and I'm adding it mostly to flag the issue for the sponsoring AD, and to make sure we cover it during IESG discussion, although again, anyone is welcome to engage.)

### Conflict with RFC 8794, potentially resolved by errata

Primarily for the AD/IESG: I happened to notice that there are 9 errata open against RFC 8794, the EMBL spec, which is a normative reference for this doc. All of them are in "reported" state so have no normative force right now. Two of them (ID 7189 and ID 7191) are added specifically to bring Matroska's usage into compliance (or rather, to redefine "compliance" to include what Matroska does).

It's not clear to me that these are proper uses of the errata process, but it's not my WG or area. In any case, it seems like this is a hint that there's a potential problem. Whether the problem should be fixed by verifying the errata, or some other way, I don't know.

Primarily for the authors:

Thanks for this document. It's well outside my comfort zone (I'm a routing protocols guy) and I appreciate the effort that's gone into making what is clearly a major piece of work accessible to someone like me.

Although I haven't completed my review, as I've gone through it I found two sections that seemed worth having a DISCUSSion about. Since the Section 10 DISCUSSion might take a while, I figured I should raise it now rather than wait to finish my entire review. So, I may add some additional comments later.

### Section 6.8

To quote §6.8 in its entirety:

  The Tags Element is most subject to changes after the file was
  originally created.  For easier editing, the Tags Element SHOULD be
  placed at the end of the Segment Element, even after the Attachments
  Element.  On the other hand, it is inconvenient to have to seek in
  the Segment for tags, especially for network streams.  So it's better
  if the Tags Element is found early in the stream.  When editing the
  Tags Element, the original Tags Element at the beginning can be
  overwritten with a Void Element and a new Tags Element written at the
  end of the Segment Element.  The file size will only marginally
  change.

I've read this several times and I just can't figure out how to reconcile "the Tags Element SHOULD be placed at the end of the Segment Element" with "it's better if the Tags Element is found early in the stream". Have I missed some subtlety in the distinction between "the Segment Element" and "the stream"? Or are you setting up a dichotomy on purpose? Or something else?

My guess is you're purposefully setting up a dichotomy (the Tags Element both should go early, and late) and then proposing a solution for it (put it early, but if it gets revised, Void it out and put the replacement late). Is that it? If so, I'd recommend rewriting to be clearer about what you're doing and not presenting the reader with a contradiction. Absent a significant rewrite, at a minimum the SHOULD has to go.

### Section 10

It seems as though there are significant unstated assumptions in the descriptions throughout this section and its subsections. I'll go into further detail on specifics below. Since the Block is such a fundamental structure for this document, it seems worth putting in some extra effort to make sure its description is clear.

In routing protocol specifications we tend to use quaint ASCII protocol packet diagrams with bit rulers along the top. Your use of variable-length fields makes this approach difficult, but I regretted not having some kind of graphical representation to reference, which might otherwise have helped. $0.02.

### Throughout, "bits" representation

In various places, you have language like "The bits 5-6 of the Block Header flags are set to 11" and similar. This language seems like it needs to be fixed, because the simplest plain English reading of the sentence (IMO anyway) is "bit 5 is set to decimal 11, and so is bit 6", which doesn't make sense. The most straightforward fix would be to write "... is set to 0b11" to indicate that you're writing the value in binary.

### Tables 36 and following, semantics

The semantics of the tables are not clear to me, and I don't see that they're defined anywhere:

Offset: What is this? All the examples are a small hex value and a plus sign. The plus sign generally means "or more" colloquially, although if this were a regex it would mean something about repetition. In any case, I don't know WHAT it means here. By the way, why are you showing these in hex and not decimal representation?

Player: This says "MUST" sometimes and is a hyphen other times. What does this mean? That a compliant Matroska Player MUST implement support for certain things (the MUSTs) and... something something I can't guess, for other things (the hyphens)?

### Section 10.1, Track Number

The first line of Table 36 description is "Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc.) (most significant bits set to increase the range)."

First, a suggestion: if you're saying "encoded as an EBML VINT" (which I think is what you mean) then say so, with xref, since that's a well-defined format with a well-defined reference. Second, a concern: since you're using a variable-length encoding here, I don't get how you can provide a specific offset for the later fields; Timestamp's location is presumably "after Track Number". Maybe that's what the "0x01+" notation means? It's telling me that Timestamp won't be any earlier than byte 1, but it might be later, depending on how Track Number is coded? But if the + means "or later" I don't see how Track Number gets 0x00+ -- what would make it start later than byte 0?

### Tables 40 and following, semantics

The various lacings have tables with a column headed "block octets" or "block octet". Given that the header is variable-length (because of the Track Number encoding) I don't see how these block octets can be known a priori. I guess perhaps the answer is "this is just an example, in a case where the Track Number happens to be encoded in a single byte, so the header occupies octets 0-3". If that is the case, I suggest stating it explicitly, perhaps in the introductory text of §10.4.

### 10.4.2 Xiph lacing, description of encoding

After looking at the example (thank you for providing this) and checking RFC 3533, I see what the coding is, but I think the description needs some work. Here's what I understand your intent to be, with some comments:

"Lacing Head on 1 Octet". I'm not able to make sense of these words, on their own. I infer from the examples that what you mean is, the first octet of the block data is a single unsigned integer that provides the number of frames in the lace minus one, meaning a lace can contain between 1 and 256 frames. Is that right?

Then that's followed by a series of integers, described as "Lacing size of each frame except the last one". These indicate the sizes of the respective lace frames other than the final one (which is inferred). If the number of frames in the lace is N, there will be N-1 integers in the list. The integers are variable-sized, and the encoding of an integer is a repetition of zero or more octets with value 255, followed by a single octet with a value less than 255. The frame size value is the sum of the octet values.

If my paragraph above is a correct description, I think your paragraph that begins "The lacing size is split into 255 values" needs work. To begin with, the plain English reading of "is split into 255 values" is "it's split into 255 distinct things", which is not what you mean.

(Update: thanks for explaining why this point was mistaken.  By the way, what happens if N=1? I appreciate that it would be silly to use anything other than the "no lacing" option in this case, but is it forbidden to encode a single frame in one of the other lacings? Given there's no way to properly do the encoding, it seems like it might be worth saying explicitly that this is a MUST NOT.)

### 10.4.3 EBML lacing, encodings

The previous point about "on 1 Octet" applies.

In this case, I have no problem with the integer coding definition, it's clear. But the example gave me difficulty in several ways.

In the second line of Table 43, you have

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame
(800 = 0x320 + 0x4000)

My first attempt at understanding how eight hundred can be equal to 0x320 + 0x4000 was a fail, because of course using the normal understanding of the "=" and "+" symbols, it can't be. My second attempt was to interpret this as saying that you're using the VINT coding, and the "=" is just (confusingly) being used to mean the colloquial English, i.e. you're saying "800, encoded in VINT as 0x4 for the VINT_WIDTH and VINT_MARKER, meaning it's two octets wide, followed by 0x0320 for the next 14 bits... and 0x320 is decimal 800."

Looking at the third line,

Block Octets Value Description

7-8 0x5e 0xd3 Size of the second frame
(500 - 800 = -300 = -0x12c + 0x1fff + 0x4000)

Once again I think the descriptive text is confusing: the size of the second frame isn't -300, though I do get that you store -300 to let the size of the second frame be computed, as 800 - 300, to give 500, which is indeed the size.

Second, "-0x12c" isn't any standard notation I'm aware of. I get that you're using it to mean "negative 300". Then 0x1fff is the hex value for (2^((7*2)-1)-1), and the addition of 0x4000 is the value for VINT_WIDTH and VINT_MARKER for a 2-octet encoding. At a minimum, I would rewrite this as "0x1fff + 0x4000 - 0x012c" to eliminate the negation sign and produce an expression that would parse, but read on.

It seems to me that readability would benefit from dividing the examples up -- a subsection on VINT/S_VINT, and a subsection on the actual Block encoding. For example, the VINT part could go something like this, inserted directly after Table 42.

  In our example, we will need to be able to represent 800, the size of
  the first frame, as a VINT. This is done using a 2 octet wide VINT as
  0x4000 + 0x0320 -- the 0x4000 is the VINT_WIDTH and VINT_MARKER, and
  the 0x0320 is the hexadecimal representation of decimal 800. The
  resulting VINT representation is 0x4320. We will also need to be able
  to represent -300, the offset required for the size of the second
  frame, as a signed VINT. This is done as 0x4000 + 0x1fff - 0x012c. In
  this expression, 0x4000 is again the VINT_WIDTH and VINT_MARKER,
  0x1fff is the hexadecimal representation of (2^((7*n)-1) - 1) for n
  of 2, and 0x012c is the hexadecimal representation of 300. The
  resulting signed VINT representation is 0x5ed3.
 
Or instead of talking about 300, you could also talk about "500 - 800", making the expression "0x4000 + 0x1fff + (0x01f4 - 0x0320)", and/or you could represent each value in the most convenient radix for clarity, as in "0x4000 + 0x1fff + (500 - 800)".
 
Then maybe you'd rewrite the descriptions in Table 43 something like

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame, 800,
encoded as a VINT

7-8 0x5e 0xd3 Offset between size of first
frame and size of second frame,
encoded as a signed VINT. To
recover the size of the second
frame, we sum this value with
the preceding frame, so,
(-300) + 800 = 500.

### 10.5, misuse of RFC 2119 keywords

  When a frame in a BlockGroup is not a RAP, all references SHOULD be
  listed as a ReferenceBlock, at least some of them,

Which is it? All? Or some of them? The RFC 2119 SHOULD is confused about what it needs to do here. Even if you remove the keyword (for example rewriting as "should"), if I were implementing this I'd have a hard time knowing what you're asking me to do.

                                                      even if not
  accurate, or one ReferenceBlock with the value "0" corresponding to a
  self or unknown reference.  The lack of ReferenceBlock would mean
  such a frame is a RAP and seeking on that frame that actually depends
  on other frames MAY create bogus output or even crash.

The RFC 2119 MAY is wrong in this context, you seem to be using it to express "might". As written, a strict reading would mean you're saying "it is explicitly OK, though optional, if implementations decide to create bogus output or crash in this case". You can fix this by replacing the MAY with "might" or "could".

[Ballot comment]
## COMMENT

### Section 7

"A reading application supporting Matroska version V MUST NOT refuse to read an application with DocReadTypeVersion equal to or lower than V even if DocTypeVersion is greater than V."

Should the second "application" be "file", making the text "... refuse to read a file with..."?

### Section 9

"For video sequences signaled as progressive, it is twice the value of DefaultDecodedFieldDuration."

What is "it"?

### Section 15.1, RFC 2119 keywords in an example

The first paragraph ends with an example, that contains MAY and SHOULD. Generally, examples are non-normative, so probably it would be better for these to be regular lower-case words and not RFC 2119 keywords. I have flagged some other cases where you do this with examples, but I probably haven't gotten all of them.

By the way, I very much appreciated all the examples used in the document, they helped a lot with my understanding.

### Section 17.1, pathological examples

The way hard linking is defined, the obvious usage is like a classic doubly-linked list... but you also allow for inference of forward and backward links if absent. I guess this is for historical reasons and to be robust in the face of weird pathologies, not because these patterns are desirable. Table 45 shows the classic doubly-linked list usage, and Tables 46-48 show what I would describe as pathological (but still permitted) cases.

Maybe I am mistaken and all of the four examples shown are equally desirable and acceptable, in which case please disregard. But if indeed one is the preferred encoding style, then this might be a case for a SHOULD (for that style) and MAY (for the others, already done in your text).

Also, this paragraph doesn't seem quite right:

  For each node of the chain of Segments of a Linked Segment at least
  one Segment MUST reference the other Segment of the node.

Specifically, I think "the other Segment of the node" should be something like "another Segment within the chain"?

### Section 18.8, "sum" or "union"?

                            The Cues Elements corresponding to such a
  virtual track SHOULD be the sum of the Cues Elements for each of the
  tracks it's composed of (when the Cues are defined per track).
 
Should "sum" be "union"? I didn't see an obvious way to (arithmetically) sum Cues Elements.

### Section 18.10, MAY instead of may?

I don't often suggest *adding* a 2119 keyword, but in the last paragraph, "Matroska Readers may" might be a good place to use the RFC 2119 MAY.

### Section 19, examples don't need 2119 keywords

In the first paragraph, again we have 2119 keywords with examples. IMHO these aren't needed.

### Section 20.2.2, wrong xref?

Is the xref to 5.1.7.1.4.14 correct? Maybe it should be to 5.1.7.4.3 or 5.1.7.4.4?

### Section 20.4

I would have benefited from a pointer to the [matroskatags] reference here:

  Each level can have different meanings for audio and video.  The
  ORIGINAL_MEDIA_TYPE tag can be used to specify a string for
  ChapterPhysicalEquiv = 60.

In Table 57, is the list of values (10..70) the only and immutable set of possible values? Might this be a candidate for having an IANA registry?

### Section 21.1 refs for JPEG/PNG

"Only JPEG and PNG image formats SHOULD be used for cover art pictures." It seems as though these should have references?

### Section 21.1, use of MAY; bullet list

Just checking: "If a selected subtitle track has some AttachmentLink elements, the player MAY use only these fonts." As I unpack this using the RFC 2119 definition, this means that it's OK for a player to restrict its font rendering of a subtitle track to only those found in the AttachmentLink element. That seems reasonable, but I'm checking because if this were a plain English "may" it would instead come out meaning that a player is not allowed to use any fonts other than those in the AttachmentLink elements. It might be well to reword the sentence to make the intended meaning a little more explicit, for example, if the first reading is the intended one it could be something like "... the player MAY restrict its font rendering to use only these fonts".

Also, this looks like a broken bullet list:

  A Matroska player SHOULD handle the official font media types from
  [RFC8081] when the system can handle the type: * font/sfnt: Generic
  SFNT Font Type, * font/ttf: TTF Font Type, * font/otf: OpenType
  Layout (OTF) Font Type, * font/collection: Collection Font Type, *
  font/woff: WOFF 1.0, * font/woff2: WOFF 2.0.
 
and so does this:

  There may also be some font attachments with the application/octet-
  stream media type.  In that case the Matroska player MAY try to guess
  the font type by checking the file extension of the
  AttachedFile\FileName string.  Common file extensions for fonts are:
  * .ttf for Truetype fonts, equivalent to font/ttf, * .otf for
  OpenType Layout fonts, equivalent to font/otf, * .ttc for Collection
  fonts, equivalent to font/collection The file extension check MUST be
  case insensitive.
 
### Section 23.1, "the following guidelines"

What are the guidelines being referred to by "The following guidelines, when followed, help reduce the number of seeking operations"? I don't see any in §23.1 itself. Maybe this is supposed to be an xref to Section 25?

### Section 23.2, TCP

In "Livestreaming of Matroska over HTTP (or any other plain protocol based on TCP) is possible", I suppose it's not actually necessary to restrict applicability to only TCP. QUIC is the elephant in the room, but presumably, Matroska doesn't really care what it's being streamed over as long as it gets reliable in-order delivery. Also, "plain protocol" isn't a well-defined term AFAIK.

### Section 25.1, lower of?

Perhaps add "the lower of" in "store no more than 5 seconds or 5 megabytes" to make it "store no more than the lower of 5 seconds or 5 megabytes"? Or "the greater of" if that's what you mean, but as written it's underspecified.

### Section 27.1, advice for DE

Since you've used the "Specification Required" policy, RFC 8126 §4.5 says

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.

Also, I notice you're using the word "reclaimed" instead of "deprecated" in this section. I think your intention is clear, but why not use "deprecated" instead? AFAIK it's the usual term for this, and indeed you use it in the title of Annex A.

## NITS

### Section 4.4

"In some situation, a Cluster Element MAY" -> "In some situations, a Cluster Element MAY" (make "situations" plural).

### Section 5.1.5

"This Element SHOULD be set when the Segment is not transmitted as a live stream (see #livestreaming)." Looks like #livestreaming is a broken xref.

### Section 17.2

The last paragraph ends in what looks like a broken bullet list.

  There are 2 ways to use a chapter link: * Linked-Duration linking, *
  Linked-Edition linking

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-cellar-matroska-16
CC @jgscudder

## DISCUSS

(This is an update to my previous ballot, to add one more question. The original ballot (below) was entirely questions for the authors (though of course, anyone is welcome to engage). The new question is primarily process-related and I'm adding it mostly to flag the issue for the sponsoring AD, and to make sure we cover it during IESG discussion, although again, anyone is welcome to engage.)

Primarily for the AD/IESG: I happened to notice that there are 9 errata open against RFC 8794, the EMBL spec, which is a normative reference for this doc. All of them are in "reported" state so have no normative force right now. Two of them (ID 7189 and ID 7191) are added specifically to bring Matroska's usage into compliance (or rather, to redefine "compliance" to include what Matroska does).

It's not clear to me that these are proper uses of the errata process, but it's not my WG or area. In any case, it seems like this is a hint that there's a potential problem. Whether the problem should be fixed by verifying the errata, or some other way, I don't know.

Primarily for the authors:

Thanks for this document. It's well outside my comfort zone (I'm a routing protocols guy) and I appreciate the effort that's gone into making what is clearly a major piece of work accessible to someone like me.

Although I haven't completed my review, as I've gone through it I found two sections that seemed worth having a DISCUSSion about. Since the Section 10 DISCUSSion might take a while, I figured I should raise it now rather than wait to finish my entire review. So, I may add some additional comments later.

### Section 6.8

To quote §6.8 in its entirety:

  The Tags Element is most subject to changes after the file was
  originally created.  For easier editing, the Tags Element SHOULD be
  placed at the end of the Segment Element, even after the Attachments
  Element.  On the other hand, it is inconvenient to have to seek in
  the Segment for tags, especially for network streams.  So it's better
  if the Tags Element is found early in the stream.  When editing the
  Tags Element, the original Tags Element at the beginning can be
  overwritten with a Void Element and a new Tags Element written at the
  end of the Segment Element.  The file size will only marginally
  change.

I've read this several times and I just can't figure out how to reconcile "the Tags Element SHOULD be placed at the end of the Segment Element" with "it's better if the Tags Element is found early in the stream". Have I missed some subtlety in the distinction between "the Segment Element" and "the stream"? Or are you setting up a dichotomy on purpose? Or something else?

My guess is you're purposefully setting up a dichotomy (the Tags Element both should go early, and late) and then proposing a solution for it (put it early, but if it gets revised, Void it out and put the replacement late). Is that it? If so, I'd recommend rewriting to be clearer about what you're doing and not presenting the reader with a contradiction. Absent a significant rewrite, at a minimum the SHOULD has to go.

### Section 10

It seems as though there are significant unstated assumptions in the descriptions throughout this section and its subsections. I'll go into further detail on specifics below. Since the Block is such a fundamental structure for this document, it seems worth putting in some extra effort to make sure its description is clear.

In routing protocol specifications we tend to use quaint ASCII protocol packet diagrams with bit rulers along the top. Your use of variable-length fields makes this approach difficult, but I regretted not having some kind of graphical representation to reference, which might otherwise have helped. $0.02.

### Throughout, "bits" representation

In various places, you have language like "The bits 5-6 of the Block Header flags are set to 11" and similar. This language seems like it needs to be fixed, because the simplest plain English reading of the sentence (IMO anyway) is "bit 5 is set to decimal 11, and so is bit 6", which doesn't make sense. The most straightforward fix would be to write "... is set to 0b11" to indicate that you're writing the value in binary.

### Tables 36 and following, semantics

The semantics of the tables are not clear to me, and I don't see that they're defined anywhere:

Offset: What is this? All the examples are a small hex value and a plus sign. The plus sign generally means "or more" colloquially, although if this were a regex it would mean something about repetition. In any case, I don't know WHAT it means here. By the way, why are you showing these in hex and not decimal representation?

Player: This says "MUST" sometimes and is a hyphen other times. What does this mean? That a compliant Matroska Player MUST implement support for certain things (the MUSTs) and... something something I can't guess, for other things (the hyphens)?

### Section 10.1, Track Number

The first line of Table 36 description is "Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc.) (most significant bits set to increase the range)."

First, a suggestion: if you're saying "encoded as an EBML VINT" (which I think is what you mean) then say so, with xref, since that's a well-defined format with a well-defined reference. Second, a concern: since you're using a variable-length encoding here, I don't get how you can provide a specific offset for the later fields; Timestamp's location is presumably "after Track Number". Maybe that's what the "0x01+" notation means? It's telling me that Timestamp won't be any earlier than byte 1, but it might be later, depending on how Track Number is coded? But if the + means "or later" I don't see how Track Number gets 0x00+ -- what would make it start later than byte 0?

### Tables 40 and following, semantics

The various lacings have tables with a column headed "block octets" or "block octet". Given that the header is variable-length (because of the Track Number encoding) I don't see how these block octets can be known a priori. I guess perhaps the answer is "this is just an example, in a case where the Track Number happens to be encoded in a single byte, so the header occupies octets 0-3". If that is the case, I suggest stating it explicitly, perhaps in the introductory text of §10.4.

### 10.4.2 Xiph lacing, description of encoding

After looking at the example (thank you for providing this) and checking RFC 3533, I see what the coding is, but I think the description needs some work. Here's what I understand your intent to be, with some comments:

"Lacing Head on 1 Octet". I'm not able to make sense of these words, on their own. I infer from the examples that what you mean is, the first octet of the block data is a single unsigned integer that provides the number of frames in the lace minus one, meaning a lace can contain between 1 and 256 frames. Is that right?

Then that's followed by a series of integers, described as "Lacing size of each frame except the last one". These indicate the sizes of the respective lace frames other than the final one (which is inferred). If the number of frames in the lace is N, there will be N-1 integers in the list. The integers are variable-sized, and the encoding of an integer is a repetition of zero or more octets with value 255, followed by a single octet with a value less than 255. The frame size value is the sum of the octet values.

If my paragraph above is a correct description, I think your paragraph that begins "The lacing size is split into 255 values" needs work. To begin with, the plain English reading of "is split into 255 values" is "it's split into 255 distinct things", which is not what you mean.

By the way, what happens if N=1? I appreciate that it would be silly to use anything other than the "no lacing" option in this case, but is it forbidden to encode a single frame in one of the other lacings? Given there's no way to properly do the encoding, it seems like it might be worth saying explicitly that this is a MUST NOT.

### 10.4.3 EBML lacing, encodings

The previous point about "on 1 Octet" applies.

In this case, I have no problem with the integer coding definition, it's clear. But the example gave me difficulty in several ways.

In the second line of Table 43, you have

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame
(800 = 0x320 + 0x4000)

My first attempt at understanding how eight hundred can be equal to 0x320 + 0x4000 was a fail, because of course using the normal understanding of the "=" and "+" symbols, it can't be. My second attempt was to interpret this as saying that you're using the VINT coding, and the "=" is just (confusingly) being used to mean the colloquial English, i.e. you're saying "800, encoded in VINT as 0x4 for the VINT_WIDTH and VINT_MARKER, meaning it's two octets wide, followed by 0x0320 for the next 14 bits... and 0x320 is decimal 800."

Looking at the third line,

Block Octets Value Description

7-8 0x5e 0xd3 Size of the second frame
(500 - 800 = -300 = -0x12c + 0x1fff + 0x4000)

Once again I think the descriptive text is confusing: the size of the second frame isn't -300, though I do get that you store -300 to let the size of the second frame be computed, as 800 - 300, to give 500, which is indeed the size.

Second, "-0x12c" isn't any standard notation I'm aware of. I get that you're using it to mean "negative 300". Then 0x1fff is the hex value for (2^((7*2)-1)-1), and the addition of 0x4000 is the value for VINT_WIDTH and VINT_MARKER for a 2-octet encoding. At a minimum, I would rewrite this as "0x1fff + 0x4000 - 0x012c" to eliminate the negation sign and produce an expression that would parse, but read on.

It seems to me that readability would benefit from dividing the examples up -- a subsection on VINT/S_VINT, and a subsection on the actual Block encoding. For example, the VINT part could go something like this, inserted directly after Table 42.

  In our example, we will need to be able to represent 800, the size of
  the first frame, as a VINT. This is done using a 2 octet wide VINT as
  0x4000 + 0x0320 -- the 0x4000 is the VINT_WIDTH and VINT_MARKER, and
  the 0x0320 is the hexadecimal representation of decimal 800. The
  resulting VINT representation is 0x4320. We will also need to be able
  to represent -300, the offset required for the size of the second
  frame, as a signed VINT. This is done as 0x4000 + 0x1fff - 0x012c. In
  this expression, 0x4000 is again the VINT_WIDTH and VINT_MARKER,
  0x1fff is the hexadecimal representation of (2^((7*n)-1) - 1) for n
  of 2, and 0x012c is the hexadecimal representation of 300. The
  resulting signed VINT representation is 0x5ed3.
 
Or instead of talking about 300, you could also talk about "500 - 800", making the expression "0x4000 + 0x1fff + (0x01f4 - 0x0320)", and/or you could represent each value in the most convenient radix for clarity, as in "0x4000 + 0x1fff + (500 - 800)".
 
Then maybe you'd rewrite the descriptions in Table 43 something like

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame, 800,
encoded as a VINT

7-8 0x5e 0xd3 Offset between size of first
frame and size of second frame,
encoded as a signed VINT. To
recover the size of the second
frame, we sum this value with
the preceding frame, so,
(-300) + 800 = 500.

### 10.5, misuse of RFC 2119 keywords

  When a frame in a BlockGroup is not a RAP, all references SHOULD be
  listed as a ReferenceBlock, at least some of them,

Which is it? All? Or some of them? The RFC 2119 SHOULD is confused about what it needs to do here. Even if you remove the keyword (for example rewriting as "should"), if I were implementing this I'd have a hard time knowing what you're asking me to do.

                                                      even if not
  accurate, or one ReferenceBlock with the value "0" corresponding to a
  self or unknown reference.  The lack of ReferenceBlock would mean
  such a frame is a RAP and seeking on that frame that actually depends
  on other frames MAY create bogus output or even crash.

The RFC 2119 MAY is wrong in this context, you seem to be using it to express "might". As written, a strict reading would mean you're saying "it is explicitly OK, though optional, if implementations decide to create bogus output or crash in this case". You can fix this by replacing the MAY with "might" or "could".

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-cellar-matroska-16
CC @jgscudder

## DISCUSS

Thanks for this document. It's well outside my comfort zone (I'm a routing protocols guy) and I appreciate the effort that's gone into making what is clearly a major piece of work accessible to someone like me.

Although I haven't completed my review, as I've gone through it I found two sections that seemed worth having a DISCUSSion about. Since the Section 10 DISCUSSion might take a while, I figured I should raise it now rather than wait to finish my entire review. So, I may add some additional comments later.

### Section 6.8

To quote §6.8 in its entirety:

  The Tags Element is most subject to changes after the file was
  originally created.  For easier editing, the Tags Element SHOULD be
  placed at the end of the Segment Element, even after the Attachments
  Element.  On the other hand, it is inconvenient to have to seek in
  the Segment for tags, especially for network streams.  So it's better
  if the Tags Element is found early in the stream.  When editing the
  Tags Element, the original Tags Element at the beginning can be
  overwritten with a Void Element and a new Tags Element written at the
  end of the Segment Element.  The file size will only marginally
  change.

I've read this several times and I just can't figure out how to reconcile "the Tags Element SHOULD be placed at the end of the Segment Element" with "it's better if the Tags Element is found early in the stream". Have I missed some subtlety in the distinction between "the Segment Element" and "the stream"? Or are you setting up a dichotomy on purpose? Or something else?

My guess is you're purposefully setting up a dichotomy (the Tags Element both should go early, and late) and then proposing a solution for it (put it early, but if it gets revised, Void it out and put the replacement late). Is that it? If so, I'd recommend rewriting to be clearer about what you're doing and not presenting the reader with a contradiction. Absent a significant rewrite, at a minimum the SHOULD has to go.

### Section 10

It seems as though there are significant unstated assumptions in the descriptions throughout this section and its subsections. I'll go into further detail on specifics below. Since the Block is such a fundamental structure for this document, it seems worth putting in some extra effort to make sure its description is clear.

In routing protocol specifications we tend to use quaint ASCII protocol packet diagrams with bit rulers along the top. Your use of variable-length fields makes this approach difficult, but I regretted not having some kind of graphical representation to reference, which might otherwise have helped. $0.02.

### Throughout, "bits" representation

In various places, you have language like "The bits 5-6 of the Block Header flags are set to 11" and similar. This language seems like it needs to be fixed, because the simplest plain English reading of the sentence (IMO anyway) is "bit 5 is set to decimal 11, and so is bit 6", which doesn't make sense. The most straightforward fix would be to write "... is set to 0b11" to indicate that you're writing the value in binary.

### Tables 36 and following, semantics

The semantics of the tables are not clear to me, and I don't see that they're defined anywhere:

Offset: What is this? All the examples are a small hex value and a plus sign. The plus sign generally means "or more" colloquially, although if this were a regex it would mean something about repetition. In any case, I don't know WHAT it means here. By the way, why are you showing these in hex and not decimal representation?

Player: This says "MUST" sometimes and is a hyphen other times. What does this mean? That a compliant Matroska Player MUST implement support for certain things (the MUSTs) and... something something I can't guess, for other things (the hyphens)?

### Section 10.1, Track Number

The first line of Table 36 description is "Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc.) (most significant bits set to increase the range)."

First, a suggestion: if you're saying "encoded as an EBML VINT" (which I think is what you mean) then say so, with xref, since that's a well-defined format with a well-defined reference. Second, a concern: since you're using a variable-length encoding here, I don't get how you can provide a specific offset for the later fields; Timestamp's location is presumably "after Track Number". Maybe that's what the "0x01+" notation means? It's telling me that Timestamp won't be any earlier than byte 1, but it might be later, depending on how Track Number is coded? But if the + means "or later" I don't see how Track Number gets 0x00+ -- what would make it start later than byte 0?

### Tables 40 and following, semantics

The various lacings have tables with a column headed "block octets" or "block octet". Given that the header is variable-length (because of the Track Number encoding) I don't see how these block octets can be known a priori. I guess perhaps the answer is "this is just an example, in a case where the Track Number happens to be encoded in a single byte, so the header occupies octets 0-3". If that is the case, I suggest stating it explicitly, perhaps in the introductory text of §10.4.

### 10.4.2 Xiph lacing, description of encoding

After looking at the example (thank you for providing this) and checking RFC 3533, I see what the coding is, but I think the description needs some work. Here's what I understand your intent to be, with some comments:

"Lacing Head on 1 Octet". I'm not able to make sense of these words, on their own. I infer from the examples that what you mean is, the first octet of the block data is a single unsigned integer that provides the number of frames in the lace minus one, meaning a lace can contain between 1 and 256 frames. Is that right?

Then that's followed by a series of integers, described as "Lacing size of each frame except the last one". These indicate the sizes of the respective lace frames other than the final one (which is inferred). If the number of frames in the lace is N, there will be N-1 integers in the list. The integers are variable-sized, and the encoding of an integer is a repetition of zero or more octets with value 255, followed by a single octet with a value less than 255. The frame size value is the sum of the octet values.

If my paragraph above is a correct description, I think your paragraph that begins "The lacing size is split into 255 values" needs work. To begin with, the plain English reading of "is split into 255 values" is "it's split into 255 distinct things", which is not what you mean.

By the way, what happens if N=1? I appreciate that it would be silly to use anything other than the "no lacing" option in this case, but is it forbidden to encode a single frame in one of the other lacings? Given there's no way to properly do the encoding, it seems like it might be worth saying explicitly that this is a MUST NOT.

### 10.4.3 EBML lacing, encodings

The previous point about "on 1 Octet" applies.

In this case, I have no problem with the integer coding definition, it's clear. But the example gave me difficulty in several ways.

In the second line of Table 43, you have

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame
(800 = 0x320 + 0x4000)

My first attempt at understanding how eight hundred can be equal to 0x320 + 0x4000 was a fail, because of course using the normal understanding of the "=" and "+" symbols, it can't be. My second attempt was to interpret this as saying that you're using the VINT coding, and the "=" is just (confusingly) being used to mean the colloquial English, i.e. you're saying "800, encoded in VINT as 0x4 for the VINT_WIDTH and VINT_MARKER, meaning it's two octets wide, followed by 0x0320 for the next 14 bits... and 0x320 is decimal 800."

Looking at the third line,

Block Octets Value Description

7-8 0x5e 0xd3 Size of the second frame
(500 - 800 = -300 = -0x12c + 0x1fff + 0x4000)

Once again I think the descriptive text is confusing: the size of the second frame isn't -300, though I do get that you store -300 to let the size of the second frame be computed, as 800 - 300, to give 500, which is indeed the size.

Second, "-0x12c" isn't any standard notation I'm aware of. I get that you're using it to mean "negative 300". Then 0x1fff is the hex value for (2^((7*2)-1)-1), and the addition of 0x4000 is the value for VINT_WIDTH and VINT_MARKER for a 2-octet encoding. At a minimum, I would rewrite this as "0x1fff + 0x4000 - 0x012c" to eliminate the negation sign and produce an expression that would parse, but read on.

It seems to me that readability would benefit from dividing the examples up -- a subsection on VINT/S_VINT, and a subsection on the actual Block encoding. For example, the VINT part could go something like this, inserted directly after Table 42.

  In our example, we will need to be able to represent 800, the size of
  the first frame, as a VINT. This is done using a 2 octet wide VINT as
  0x4000 + 0x0320 -- the 0x4000 is the VINT_WIDTH and VINT_MARKER, and
  the 0x0320 is the hexadecimal representation of decimal 800. The
  resulting VINT representation is 0x4320. We will also need to be able
  to represent -300, the offset required for the size of the second
  frame, as a signed VINT. This is done as 0x4000 + 0x1fff - 0x012c. In
  this expression, 0x4000 is again the VINT_WIDTH and VINT_MARKER,
  0x1fff is the hexadecimal representation of (2^((7*n)-1) - 1) for n
  of 2, and 0x012c is the hexadecimal representation of 300. The
  resulting signed VINT representation is 0x5ed3.
 
Or instead of talking about 300, you could also talk about "500 - 800", making the expression "0x4000 + 0x1fff + (0x01f4 - 0x0320)", and/or you could represent each value in the most convenient radix for clarity, as in "0x4000 + 0x1fff + (500 - 800)".
 
Then maybe you'd rewrite the descriptions in Table 43 something like

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame, 800,
encoded as a VINT

7-8 0x5e 0xd3 Offset between size of first
frame and size of second frame,
encoded as a signed VINT. To
recover the size of the second
frame, we sum this value with
the preceding frame, so,
(-300) + 800 = 500.

### 10.5, misuse of RFC 2119 keywords

  When a frame in a BlockGroup is not a RAP, all references SHOULD be
  listed as a ReferenceBlock, at least some of them,

Which is it? All? Or some of them? The RFC 2119 SHOULD is confused about what it needs to do here. Even if you remove the keyword (for example rewriting as "should"), if I were implementing this I'd have a hard time knowing what you're asking me to do.

                                                      even if not
  accurate, or one ReferenceBlock with the value "0" corresponding to a
  self or unknown reference.  The lack of ReferenceBlock would mean
  such a frame is a RAP and seeking on that frame that actually depends
  on other frames MAY create bogus output or even crash.

The RFC 2119 MAY is wrong in this context, you seem to be using it to express "might". As written, a strict reading would mean you're saying "it is explicitly OK, though optional, if implementations decide to create bogus output or crash in this case". You can fix this by replacing the MAY with "might" or "could".

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-cellar-matroska-16
CC @jgscudder

## DISCUSS

Thanks for this document. It's well outside my comfort zone (I'm a routing protocols guy) and I appreciate the effort that's gone into making what is clearly a major piece of work accessible to someone like me.

Although I haven't completed my review, as I've gone through it I found two sections that seemed worth having a DISCUSSion about. Since the Section 10 DISCUSSion might take a while, I figured I should raise it now rather than wait to finish my entire review. So, I may add some additional comments later.

### Section 6.8

To quote §6.8 in its entirety:

  The Tags Element is most subject to changes after the file was
  originally created.  For easier editing, the Tags Element SHOULD be
  placed at the end of the Segment Element, even after the Attachments
  Element.  On the other hand, it is inconvenient to have to seek in
  the Segment for tags, especially for network streams.  So it's better
  if the Tags Element is found early in the stream.  When editing the
  Tags Element, the original Tags Element at the beginning can be
  overwritten with a Void Element and a new Tags Element written at the
  end of the Segment Element.  The file size will only marginally
  change.

I've read this several times and I just can't figure out how to reconcile "the Tags Element SHOULD be placed at the end of the Segment Element" with "it's better if the Tags Element is found early in the stream". Have I missed some subtlety in the distinction between "the Segment Element" and "the stream"? Or are you setting up a dichotomy on purpose? Or something else?

My guess is you're purposefully setting up a dichotomy (the Tags Element both should go early, and late) and then proposing a solution for it (put it early, but if it gets revised, Void it out and put the replacement late). Is that it? If so, I'd recommend rewriting to be clearer about what you're doing and not presenting the reader with a contradiction. Absent a significant rewrite, at a minimum the SHOULD has to go.

### Section 10

It seems as though there are significant unstated assumptions in the descriptions throughout this section and its subsections. I'll go into further detail on specifics below. Since the Block is such a fundamental structure for this document, it seems worth putting in some extra effort to make sure its description is clear.

In routing protocol specifications we tend to use quaint ASCII protocol packet diagrams with bit rulers along the top. Your use of variable-length fields makes this approach difficult, but I regretted not having some kind of graphical representation to reference, which might otherwise have helped. $0.02.

### Throughout, "bits" representation

In various places, you have language like "The bits 5-6 of the Block Header flags are set to 11" and similar. This language seems like it needs to be fixed, because the simplest plain English reading of the sentence (IMO anyway) is "bit 5 is set to decimal 11, and so is bit 6", which doesn't make sense. The most straightforward fix would be to write "... is set to 0b11" to indicate that you're writing the value in binary.

### Tables 36 and following, semantics

The semantics of the tables are not clear to me, and I don't see that they're defined anywhere:

Offset: What is this? All the examples are a small hex value and a plus sign. The plus sign generally means "or more" colloquially, although if this were a regex it would mean something about repetition. In any case, I don't know WHAT it means here. By the way, why are you showing these in hex and not decimal representation?

Player: This says "MUST" sometimes and is a hyphen other times. What does this mean? That a compliant Matroska Player MUST implement support for certain things (the MUSTs) and... something something I can't guess, for other things (the hyphens)?

### Section 10.1, Track Number

The first line of Table 36 description is "Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc.) (most significant bits set to increase the range)."

First, a suggestion: if you're saying "encoded as an EBML VINT" (which I think is what you mean) then say so, with xref, since that's a well-defined format with a well-defined reference. Second, a concern: since you're using a variable-length encoding here, I don't get how you can provide a specific offset for the later fields; Timestamp's location is presumably "after Track Number". Maybe that's what the "0x01+" notation means? It's telling me that Timestamp won't be any earlier than byte 1, but it might be later, depending on how Track Number is coded? But if the + means "or later" I don't see how Track Number gets 0x00+ -- what would make it start later than byte 0?

### Tables 40 and following, semantics

The various lacings have tables with a column headed "block octets" or "block octet". Given that the header is variable-length (because of the Track Number encoding) I don't see how these block octets can be known a priori. I guess perhaps the answer is "this is just an example, in a case where the Track Number happens to be encoded in a single byte, so the header occupies octets 0-3". If that is the case, I suggest stating it explicitly, perhaps in the introductory text of §10.4.

### 10.4.2 Xiph lacing, description of encoding

After looking at the example (thank you for providing this) and checking RFC 3533, I see what the coding is, but I think the description needs some work. Here's what I understand your intent to be, with some comments:

"Lacing Head on 1 Octet". I'm not able to make sense of these words, on their own. I infer from the examples that what you mean is, the first octet of the block data is a single unsigned integer that provides the number of frames in the lace minus one, meaning a lace can contain between 1 and 256 frames. Is that right?

Then that's followed by a series of integers, described as "Lacing size of each frame except the last one". These indicate the sizes of the respective lace frames other than the final one (which is inferred). If the number of frames in the lace is N, there will be N-1 integers in the list. The integers are variable-sized, and the encoding of an integer is a repetition of zero or more octets with value 255, followed by a single octet with a value less than 255. The frame size value is the sum of the octet values.

If my paragraph above is a correct description, I think your paragraph that begins "The lacing size is split into 255 values" needs work. To begin with, the plain English reading of "is split into 255 values" is "it's split into 255 distinct things", which is not what you mean.

By the way, what happens if N=1? I appreciate that it would be silly to use anything other than the "no lacing" option in this case, but is it forbidden to encode a single frame in one of the other lacings? Given there's no way to properly do the encoding, it seems like it might be worth saying explicitly that this is a MUST NOT.

### 10.4.3 EBML lacing, encodings

The previous point about "on 1 Octet" applies.

In this case, I have no problem with the integer coding definition, it's clear. But the example gave me difficulty in several ways.

In the second line of Table 43, you have

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame
(800 = 0x320 + 0x4000)

My first attempt at understanding how eight hundred can be equal to 0x320 + 0x4000 was a fail, because of course using the normal understanding of the "=" and "+" symbols, it can't be. My second attempt was to interpret this as saying that you're using the VINT coding, and the "=" is just (confusingly) being used to mean the colloquial English, i.e. you're saying "800, encoded in VINT as 0x4 for the VINT_WIDTH and VINT_MARKER, meaning it's two octets wide, followed by 0x0320 for the next 14 bits... and 0x320 is decimal 800."

Looking at the third line,

Block Octets Value Description

7-8 0x5e 0xd3 Size of the second frame
(500 - 800 = -300 = -0x12c + 0x1fff + 0x4000)

Once again I think the descriptive text is confusing: the size of the second frame isn't -300, though I do get that you store -300 to let the size of the second frame be computed, as 800 - 300, to give 500, which is indeed the size.

Second, "-0x12c" isn't any standard notation I'm aware of. I get that you're using it to mean "negative 300". Then 0x1fff is the hex value for (2^((7*2)-1)-1), and the addition of 0x4000 is the value for VINT_WIDTH and VINT_MARKER for a 2-octet encoding. At a minimum, I would rewrite this as "0x1fff + 0x4000 - 0x012c" to eliminate the negation sign and produce an expression that would parse, but read on.

It seems to me that readability would benefit from dividing the examples up -- a subsection on VINT/S_VINT, and a subsection on the actual Block encoding. For example, the VINT part could go something like this, inserted directly after Table 42.

  In our example, we will need to be able to represent 800, the size of
  the first frame, as a VINT. This is done using a 2 octet wide VINT as
  0x4000 + 0x0320 -- the 0x4000 is the VINT_WIDTH and VINT_MARKER, and
  the 0x0320 is the hexadecimal representation of decimal 800. The
  resulting VINT representation is 0x4320. We will also need to be able
  to represent -300, the offset required for the size of the second
  frame, as a signed VINT. This is done as 0x4000 + 0x1fff - 0x012c. In
  this expression, 0x4000 is again the VINT_WIDTH and VINT_MARKER,
  0x1fff is the hexadecimal representation of (2^((7*n)-1) - 1) for n
  of 2, and 0x012c is the hexadecimal representation of 300. The
  resulting signed VINT representation is 0x5ed3.
 
Or instead of talking about 300, you could also talk about "500 - 800", making the expression "0x4000 + 0x1fff + (0x01f4 - 0x0320)", and/or you could represent each value in the most convenient radix for clarity, as in "0x4000 + 0x1fff + (500 - 800)".
 
Then maybe you'd rewrite the descriptions in Table 43 something like

Block Octets Value Description

5-6 0x43 0x20 Size of the first frame, 800,
encoded as a VINT

7-8 0x5e 0xd3 Offset between size of first
frame and size of second frame,
encoded as a signed VINT. To
recover the size of the second
frame, we sum this value with
the preceding frame, so,
(-300) + 800 = 500.

### 10.5, misuse of RFC 2119 keywords

  When a frame in a BlockGroup is not a RAP, all references SHOULD be
  listed as a ReferenceBlock, at least some of them,

Which is it? All? Or some of them? The RFC 2119 SHOULD is confused about what it needs to do here. Even if you remove the keyword (for example rewriting as "should"), if I were implementing this I'd have a hard time knowing what you're asking me to do.

                                                      even if not
  accurate, or one ReferenceBlock with the value "0" corresponding to a
  self or unknown reference.  The lack of ReferenceBlock would mean
  such a frame is a RAP and seeking on that frame that actually depends
  on other frames MAY create bogus output or even crash.

The RFC 2119 MAY is wrong in this context, you seem to be using it to express "might". As written, a strict reading would mean you're saying "it is explicitly OK, though optional, if implementations decide to create bogus output or crash in this case". You can fix this by replacing the MAY with "might" or "could".

[Ballot comment]
## COMMENT

### Section 7

"A reading application supporting Matroska version V MUST NOT refuse to read an application with DocReadTypeVersion equal to or lower than V even if DocTypeVersion is greater than V."

Should the second "application" be "file", making the text "... refuse to read a file with..."?

### Section 9

"For video sequences signaled as progressive, it is twice the value of DefaultDecodedFieldDuration."

What is "it"?

## NITS

### Section 4.4

"In some situation, a Cluster Element MAY" -> "In some situations, a Cluster Element MAY" (make "situations" plural).

### Section 5.1.5

"This Element SHOULD be set when the Segment is not transmitted as a live stream (see #livestreaming)." Looks like #livestreaming is a broken xref.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
Thanks for this specification. I have reviewed the document and have not identified transport related issues.

However, I have two observation/questions that I would like to discuss to have clear opinions and better understanding.

    - Top-Level Elements are optional fields in the segment. While segment is a MUST part in the container but segments values (elements) are MAY, this to me says one can just put a dummy segment in the container and it will be fine. is that correct interpretation? however, there is a RECOMMENDED segment element, so how should we interpret the statement that Top-level Elements are all MAY? 

    - Even if the Top-Level Elements MAY be available in the container, some of the elements has MUST parts when they are present. However, I have not notices description of the consequences or error handling is those MUST parts are not available in the elements. I wonder what would be the course of action if the MUST parts of a certain element is not there. In general, I was expecting error handling in this specification which is not there and would like to discuss the reasoning behind it.

[Ballot discuss]
Thanks for this specification. I have reviewed the document and have not identified transport related issues.

However, I have two observation/questions that I would like to discuss to have clear opinions and better understanding.

    - Top-Level Elements are optional fields in the segment. While segment is a MUST part in the container but segments values (elements) are MAY, this to me says one can just put a dummy segment in the container and it will be fine. is that correct interpretation? however, there is a RECOMMENDED segment element, so how should we interpret the statement that Top-level Elements are all MAY? 
    - Even if the Top-Level Elements MAY be available in the container, some of the elements has MUST parts when they are present. However, I have not notices description of the consequences or error handling is those MUST parts are not available in the elements. I wonder what would be the course of action if the MUST parts of a certain element is not there. In general, I was expecting error handling in this specification which is not there and would like to discuss the reasoning behind it.

[Ballot comment]
I am balloting "NoObj" in the "I read the protocol action, and this is outside my area of expertise" sense of the term.

I read much of the document, but ¯\_(ツ)_/¯.

[Ballot comment]
# Internet AD comments for draft-ietf-cellar-matroska-16
CC @ekline

comment syntax: https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

### S4.4

* s/comprised of/comprising/

  or

  s/comprised of/composed of/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cellar-matroska-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, a new registry is to be created called the Matroska Element IDs registry.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

Element IDs are encoded using the VINT mechanism described in Section 4 of [RFC8794] and can be between one and five octets long. Five-octet-long Element IDs are possible only if declared in the EBML header.

One-octet Matroska Element IDs are to be allocated according to the "RFC Required" policy [RFC8126].

Two-octet Matroska Element IDs are to be allocated according to the "Specification Required" policy [RFC8126].

Three-octet and four-octet Matroska Element IDs are to be allocated according to the "First Come First Served" policy [RFC8126].

IANA QUESTION --> What is the allocation policy for five-octet Matroska Element IDs?

The registry will be preceded by the following informational note:

"Elements found in Section 28 of [ RFC-to-be ] have an assigned Matroska Element ID for historical reasons. These elements are not in use and SHOULD NOT be reused unless there are no other IDs available with the desired size. Such IDs are considered as reclaimed to the IANA registry as they could be used for other things in the future."

There are initial registrations in the new registry as follows:

Element ID Element Name Reference
---------------+----------------------------+------------------------------------------------
0x80 ChapterDisplay [ RFC-to-be; Section 5.1.7.1.4.9 ]
0x83 TrackType [ RFC-to-be; Section 5.1.4.1.3 ]
0x85 ChapString [ RFC-to-be; Section 5.1.7.1.4.10 ]
0x86 CodecID [ RFC-to-be; Section 5.1.4.1.21 ]
0x88 FlagDefault [ RFC-to-be; Section 5.1.4.1.5 ]
0x8E Slices [ RFC-to-be; Reclaimed in Section 28.5 ]
0x91 ChapterTimeStart [ RFC-to-be; Section 5.1.7.1.4.3 ]
0x92 ChapterTimeEnd [ RFC-to-be; Section 5.1.7.1.4.4 ]
0x96 CueRefTime [ RFC-to-be; Section 5.1.5.1.2.8 ]
0x97 CueRefCluster [ RFC-to-be; Reclaimed in Section 28.36 ]
0x98 ChapterFlagHidden [ RFC-to-be; Section 5.1.7.1.4.5 ]
0x9A FlagInterlaced [ RFC-to-be; Section 5.1.4.1.29.1 ]
0x9B BlockDuration [ RFC-to-be; Section 5.1.3.5.3 ]
0x9C FlagLacing [ RFC-to-be; Section 5.1.4.1.12 ]
0x9D FieldOrder [ RFC-to-be; Section 5.1.4.1.29.2 ]
0x9F Channels [ RFC-to-be; Section 5.1.4.1.30.3 ]
0xA0 BlockGroup [ RFC-to-be; Section 5.1.3.5 ]
0xA1 Block [ RFC-to-be; Section 5.1.3.5.1 ]
0xA2 BlockVirtual [ RFC-to-be; Reclaimed in Section 28.) ]
0xA3 SimpleBlock [ RFC-to-be; Section 5.1.3.4 ]
0xA4 CodecState [ RFC-to-be; Section 5.1.3.5.6 ]
0xA5 BlockAdditional [ RFC-to-be; Section 5.1.3.5.2.2 ]
0xA6 BlockMore [ RFC-to-be; Section 5.1.3.5.2.1 ]
0xA7 Position [ RFC-to-be; Section 5.1.3.2 ]
0xAA CodecDecodeAll [ RFC-to-be; Reclaimed in Section 28.22 ]
0xAB PrevSize [ RFC-to-be; Section 5.1.3.3 ]
0xAE TrackEntry [ RFC-to-be; Section 5.1.4.1 ]
0xAF EncryptedBlock [ RFC-to-be; Reclaimed in Section 28.15 ]
0xB0 PixelWidth [ RFC-to-be; Section 5.1.4.1.29.6 ]
0xB2 CueDuration [ RFC-to-be; Section 5.1.5.1.2.4 ]
0xB3 CueTime [ RFC-to-be; Section 5.1.5.1.1 ]
0xB5 SamplingFrequency [ RFC-to-be; Section 5.1.4.1.30.1 ]
0xB6 ChapterAtom [ RFC-to-be; Section 5.1.7.1.4 ]
0xB7 CueTrackPositions [ RFC-to-be; Section 5.1.5.1.2 ]
0xB9 FlagEnabled [ RFC-to-be; Section 5.1.4.1.4 ]
0xBA PixelHeight [ RFC-to-be; Section 5.1.4.1.29.7 ]
0xBB CuePoint [ RFC-to-be; Section 5.1.5.1 ]
0xC0 TrickTrackUID [ RFC-to-be; Reclaimed in Section 28.27 ]
0xC1 TrickTrackSegmentUID [ RFC-to-be; Reclaimed in Section 28.28 ]
0xC4 TrickMasterTrackSegmentUID [ RFC-to-be; Reclaimed in Section 28.31 ]
0xC6 TrickTrackFlag [ RFC-to-be; Reclaimed in Section 28.29 ]
0xC7 TrickMasterTrackUID [ RFC-to-be; Reclaimed in Section 28.30 ]
0xC8 ReferenceFrame [ RFC-to-be; Reclaimed in Section 28.12 ]
0xC9 ReferenceOffset [ RFC-to-be; Reclaimed in Section 28.13 ]
0xCA ReferenceTimestamp [ RFC-to-be; Reclaimed in Section 28.14 ]
0xCB BlockAdditionID [ RFC-to-be; Reclaimed in Section 28.9 ]
0xCC LaceNumber [ RFC-to-be; Reclaimed in Section 28.7 ]
0xCD FrameNumber [ RFC-to-be; Reclaimed in Section 28.8 ]
0xCE Delay [ RFC-to-be; Reclaimed in Section 28.10 ]
0xCF SliceDuration [ RFC-to-be; Reclaimed in Section 28.11 ]
0xD7 TrackNumber [ RFC-to-be; Section 5.1.4.1.1 ]
0xDB CueReference [ RFC-to-be; Section 5.1.5.1.2.7 ]
0xE0 Video [ RFC-to-be; Section 5.1.4.1.29 ]
0xE1 Audio [ RFC-to-be; Section 5.1.4.1.30 ]
0xE2 TrackOperation [ RFC-to-be; Section 5.1.4.1.31 ]
0xE3 TrackCombinePlanes [ RFC-to-be; Section 5.1.4.1.31.1 ]
0xE4 TrackPlane [ RFC-to-be; Section 5.1.4.1.31.2 ]
0xE5 TrackPlaneUID [ RFC-to-be; Section 5.1.4.1.31.3 ]
0xE6 TrackPlaneType [ RFC-to-be; Section 5.1.4.1.31.4 ]
0xE7 Timestamp [ RFC-to-be; Section 5.1.3.1 ]
0xE8 TimeSlice [ RFC-to-be; Reclaimed in Section 28.6 ]
0xE9 TrackJoinBlocks [ RFC-to-be; Section 5.1.4.1.31.5 ]
0xEA CueCodecState [ RFC-to-be; Section 5.1.5.1.2.6 ]
0xEB CueRefCodecState [ RFC-to-be; Reclaimed in Section 28.38 ]
0xED TrackJoinUID [ RFC-to-be; Section 5.1.4.1.31.6 ]
0xEE BlockAddID [ RFC-to-be; Section 5.1.3.5.2.3 ]
0xF0 CueRelativePosition [ RFC-to-be; Section 5.1.5.1.2.3 ]
0xF1 CueClusterPosition [ RFC-to-be; Section 5.1.5.1.2.2 ]
0xF7 CueTrack [ RFC-to-be; Section 5.1.5.1.2.1 ]
0xFA ReferencePriority [ RFC-to-be; Section 5.1.3.5.4 ]
0xFB ReferenceBlock [ RFC-to-be; Section 5.1.3.5.5 ]
0xFD ReferenceVirtual [ RFC-to-be; Reclaimed in Section 28.4 ]
0x41A4 BlockAddIDName [ RFC-to-be; Section 5.1.4.1.17.2 ]
0x41E4 BlockAdditionMapping [ RFC-to-be; Section 5.1.4.1.17 ]
0x41E7 BlockAddIDType [ RFC-to-be; Section 5.1.4.1.17.3 ]
0x41ED BlockAddIDExtraData [ RFC-to-be; Section 5.1.4.1.17.4 ]
0x41F0 BlockAddIDValue [ RFC-to-be; Section 5.1.4.1.17.1 ]
0x4254 ContentCompAlgo [ RFC-to-be; Section 5.1.4.1.32.6 ]
0x4255 ContentCompSettings [ RFC-to-be; Section 5.1.4.1.32.7 ]
0x437C ChapLanguage [ RFC-to-be; Section 5.1.7.1.4.11 ]
0x437D ChapLanguageBCP47 [ RFC-to-be; Section 5.1.7.1.4.12 ]
0x437E ChapCountry [ RFC-to-be; Section 5.1.7.1.4.13 ]
0x4444 SegmentFamily [ RFC-to-be; Section 5.1.2.7 ]
0x4461 DateUTC [ RFC-to-be; Section 5.1.2.11 ]
0x447A TagLanguage [ RFC-to-be; Section 5.1.8.1.2.2 ]
0x447B TagLanguageBCP47 [ RFC-to-be; Section 5.1.8.1.2.3 ]
0x4484 TagDefault [ RFC-to-be; Section 5.1.8.1.2.4 ]
0x4485 TagBinary [ RFC-to-be; Section 5.1.8.1.2.6 ]
0x4487 TagString [ RFC-to-be; Section 5.1.8.1.2.5 ]
0x4489 Duration [ RFC-to-be; Section 5.1.2.10 ]
0x44B4 TagDefaultBogus [ RFC-to-be; Reclaimed in Section 28.42 ]
0x450D ChapProcessPrivate [ RFC-to-be; Section 5.1.7.1.4.16 ]
0x45A3 TagName [ RFC-to-be; Section 5.1.8.1.2.1 ]
0x45B9 EditionEntry [ RFC-to-be; Section 5.1.7.1 ]
0x45BC EditionUID [ RFC-to-be; Section 5.1.7.1.1 ]
0x45DB EditionFlagDefault [ RFC-to-be; Section 5.1.7.1.2 ]
0x45DD EditionFlagOrdered [ RFC-to-be; Section 5.1.7.1.3 ]
0x465C FileData [ RFC-to-be; Section 5.1.6.1.4 ]
0x4660 FileMediaType [ RFC-to-be; Section 5.1.6.1.3 ]
0x4661 FileUsedStartTime [ RFC-to-be; Reclaimed in Section 28.40 ]
0x4662 FileUsedEndTime [ RFC-to-be; Reclaimed in Section 28.41 ]
0x466E FileName [ RFC-to-be; Section 5.1.6.1.2 ]
0x4675 FileReferral [ RFC-to-be; Reclaimed in Section 28.39 ]
0x467E FileDescription [ RFC-to-be; Section 5.1.6.1.1 ]
0x46AE FileUID [ RFC-to-be; Section 5.1.6.1.5 ]
0x47E1 ContentEncAlgo [ RFC-to-be; Section 5.1.4.1.32.9 ]
0x47E2 ContentEncKeyID [ RFC-to-be; Section 5.1.4.1.32.10 ]
0x47E3 ContentSignature [ RFC-to-be; Reclaimed in Section 28.32 ]
0x47E4 ContentSigKeyID [ RFC-to-be; Reclaimed in Section 28.33 ]
0x47E5 ContentSigAlgo [ RFC-to-be; Reclaimed in Section 28.34 ]
0x47E6 ContentSigHashAlgo [ RFC-to-be; Reclaimed in Section 28.35 ]
0x47E7 ContentEncAESSettings [ RFC-to-be; Section 5.1.4.1.32.11 ]
0x47E8 AESSettingsCipherMode [ RFC-to-be; Section 5.1.4.1.32.12 ]
0x4D80 MuxingApp [ RFC-to-be; Section 5.1.2.13 ]
0x4DBB Seek [ RFC-to-be; Section 5.1.1.1 ]
0x5031 ContentEncodingOrder [ RFC-to-be; Section 5.1.4.1.32.2 ]
0x5032 ContentEncodingScope [ RFC-to-be; Section 5.1.4.1.32.3 ]
0x5033 ContentEncodingType [ RFC-to-be; Section 5.1.4.1.32.4 ]
0x5034 ContentCompression [ RFC-to-be; Section 5.1.4.1.32.5 ]
0x5035 ContentEncryption [ RFC-to-be; Section 5.1.4.1.32.8 ]
0x535F CueRefNumber [ RFC-to-be; Reclaimed in Section 28.37 ]
0x536E Name [ RFC-to-be; Section 5.1.4.1.18 ]
0x5378 CueBlockNumber [ RFC-to-be; Section 5.1.5.1.2.5 ]
0x537F TrackOffset [ RFC-to-be; Reclaimed in Section 28.18 ]
0x53AB SeekID [ RFC-to-be; Section 5.1.1.1.1 ]
0x53AC SeekPosition [ RFC-to-be; Section 5.1.1.1.2 ]
0x53B8 StereoMode [ RFC-to-be; Section 5.1.4.1.29.3 ]
0x53B9 OldStereoMode [ RFC-to-be; Section 5.1.4.1.29.5 ]
0x53C0 AlphaMode [ RFC-to-be; Section 5.1.4.1.29.4 ]
0x54AA PixelCropBottom [ RFC-to-be; Section 5.1.4.1.29.8 ]
0x54B0 DisplayWidth [ RFC-to-be; Section 5.1.4.1.29.12 ]
0x54B2 DisplayUnit [ RFC-to-be; Section 5.1.4.1.29.14 ]
0x54B3 AspectRatioType [ RFC-to-be; Reclaimed in Section 28.23 ]
0x54BA DisplayHeight [ RFC-to-be; Section 5.1.4.1.29.13 ]
0x54BB PixelCropTop [ RFC-to-be; Section 5.1.4.1.29.9 ]
0x54CC PixelCropLeft [ RFC-to-be; Section 5.1.4.1.29.10 ]
0x54DD PixelCropRight [ RFC-to-be; Section 5.1.4.1.29.11 ]
0x55AA FlagForced [ RFC-to-be; Section 5.1.4.1.6 ]
0x55AB FlagHearingImpaired [ RFC-to-be; Section 5.1.4.1.7 ]
0x55AC FlagVisualImpaired [ RFC-to-be; Section 5.1.4.1.8 ]
0x55AD FlagTextDescriptions [ RFC-to-be; Section 5.1.4.1.9 ]
0x55AE FlagOriginal [ RFC-to-be; Section 5.1.4.1.10 ]
0x55AF FlagCommentary [ RFC-to-be; Section 5.1.4.1.11 ]
0x55B0 Colour [ RFC-to-be; Section 5.1.4.1.29.16 ]
0x55B1 MatrixCoefficients [ RFC-to-be; Section 5.1.4.1.29.17 ]
0x55B2 BitsPerChannel [ RFC-to-be; Section 5.1.4.1.29.18 ]
0x55B3 ChromaSubsamplingHorz [ RFC-to-be; Section 5.1.4.1.29.19 ]
0x55B4 ChromaSubsamplingVert [ RFC-to-be; Section 5.1.4.1.29.20 ]
0x55B5 CbSubsamplingHorz [ RFC-to-be; Section 5.1.4.1.29.21 ]
0x55B6 CbSubsamplingVert [ RFC-to-be; Section 5.1.4.1.29.22 ]
0x55B7 ChromaSitingHorz [ RFC-to-be; Section 5.1.4.1.29.23 ]
0x55B8 ChromaSitingVert [ RFC-to-be; Section 5.1.4.1.29.24 ]
0x55B9 Range [ RFC-to-be; Section 5.1.4.1.29.25 ]
0x55BA TransferCharacteristics [ RFC-to-be; Section 5.1.4.1.29.26 ]
0x55BB Primaries [ RFC-to-be; Section 5.1.4.1.29.27 ]
0x55BC MaxCLL [ RFC-to-be; Section 5.1.4.1.29.28 ]
0x55BD MaxFALL [ RFC-to-be; Section 5.1.4.1.29.29 ]
0x55D0 MasteringMetadata [ RFC-to-be; Section 5.1.4.1.29.30 ]
0x55D1 PrimaryRChromaticityX [ RFC-to-be; Section 5.1.4.1.29.31 ]
0x55D2 PrimaryRChromaticityY [ RFC-to-be; Section 5.1.4.1.29.32 ]
0x55D3 PrimaryGChromaticityX [ RFC-to-be; Section 5.1.4.1.29.33 ]
0x55D4 PrimaryGChromaticityY [ RFC-to-be; Section 5.1.4.1.29.34 ]
0x55D5 PrimaryBChromaticityX [ RFC-to-be; Section 5.1.4.1.29.35 ]
0x55D6 PrimaryBChromaticityY [ RFC-to-be; Section 5.1.4.1.29.36 ]
0x55D7 WhitePointChromaticityX [ RFC-to-be; Section 5.1.4.1.29.37 ]
0x55D8 WhitePointChromaticityY [ RFC-to-be; Section 5.1.4.1.29.38 ]
0x55D9 LuminanceMax [ RFC-to-be; Section 5.1.4.1.29.39 ]
0x55DA LuminanceMin [ RFC-to-be; Section 5.1.4.1.29.40 ]
0x55EE MaxBlockAdditionID [ RFC-to-be; Section 5.1.4.1.16 ]
0x5654 ChapterStringUID [ RFC-to-be; Section 5.1.7.1.4.2 ]
0x56AA CodecDelay [ RFC-to-be; Section 5.1.4.1.26 ]
0x56BB SeekPreRoll [ RFC-to-be; Section 5.1.4.1.27 ]
0x5741 WritingApp [ RFC-to-be; Section 5.1.2.14 ]
0x5854 SilentTracks [ RFC-to-be; Reclaimed in Section 28.1 ]
0x58D7 SilentTrackNumber [ RFC-to-be; Reclaimed in Section 28.2 ]
0x61A7 AttachedFile [ RFC-to-be; Section 5.1.6.1 ]
0x6240 ContentEncoding [ RFC-to-be; Section 5.1.4.1.32.1 ]
0x6264 BitDepth [ RFC-to-be; Section 5.1.4.1.30.4 ]
0x63A2 CodecPrivate [ RFC-to-be; Section 5.1.4.1.22 ]
0x63C0 Targets [ RFC-to-be; Section 5.1.8.1.1 ]
0x63C3 ChapterPhysicalEquiv [ RFC-to-be; Section 5.1.7.1.4.8 ]
0x63C4 TagChapterUID [ RFC-to-be; Section 5.1.8.1.1.5 ]
0x63C5 TagTrackUID [ RFC-to-be; Section 5.1.8.1.1.3 ]
0x63C6 TagAttachmentUID [ RFC-to-be; Section 5.1.8.1.1.6 ]
0x63C9 TagEditionUID [ RFC-to-be; Section 5.1.8.1.1.4 ]
0x63CA TargetType [ RFC-to-be; Section 5.1.8.1.1.2 ]
0x6624 TrackTranslate [ RFC-to-be; Section 5.1.4.1.28 ]
0x66A5 TrackTranslateTrackID [ RFC-to-be; Section 5.1.4.1.28.1 ]
0x66BF TrackTranslateCodec [ RFC-to-be; Section 5.1.4.1.28.2 ]
0x66FC TrackTranslateEditionUID [ RFC-to-be; Section 5.1.4.1.28.3 ]
0x67C8 SimpleTag [ RFC-to-be; Section 5.1.8.1.2 ]
0x68CA TargetTypeValue [ RFC-to-be; Section 5.1.8.1.1.1 ]
0x6911 ChapProcessCommand [ RFC-to-be; Section 5.1.7.1.4.17 ]
0x6922 ChapProcessTime [ RFC-to-be; Section 5.1.7.1.4.18 ]
0x6924 ChapterTranslate [ RFC-to-be; Section 5.1.2.8 ]
0x6933 ChapProcessData [ RFC-to-be; Section 5.1.7.1.4.19 ]
0x6944 ChapProcess [ RFC-to-be; Section 5.1.7.1.4.14 ]
0x6955 ChapProcessCodecID [ RFC-to-be; Section 5.1.7.1.4.15 ]
0x69A5 ChapterTranslateID [ RFC-to-be; Section 5.1.2.8.1 ]
0x69BF ChapterTranslateCodec [ RFC-to-be; Section 5.1.2.8.2 ]
0x69FC ChapterTranslateEditionUID [ RFC-to-be; Section 5.1.2.8.3 ]
0x6D80 ContentEncodings [ RFC-to-be; Section 5.1.4.1.32 ]
0x6DE7 MinCache [ RFC-to-be; Reclaimed in Section 28.16 ]
0x6DF8 MaxCache [ RFC-to-be; Reclaimed in Section 28.17 ]
0x6E67 ChapterSegmentUUID [ RFC-to-be; Section 5.1.7.1.4.6 ]
0x6EBC ChapterSegmentEditionUID [ RFC-to-be; Section 5.1.7.1.4.7 ]
0x6FAB TrackOverlay [ RFC-to-be; Section 5.1.4.1.25 ]
0x7373 Tag [ RFC-to-be; Section 5.1.8.1 ]
0x7384 SegmentFilename [ RFC-to-be; Section 5.1.2.2 ]
0x73A4 SegmentUUID [ RFC-to-be; Section 5.1.2.1 ]
0x73C4 ChapterUID [ RFC-to-be; Section 5.1.7.1.4.1 ]
0x73C5 TrackUID [ RFC-to-be; Section 5.1.4.1.2 ]
0x7446 AttachmentLink [ RFC-to-be; Section 5.1.4.1.24 ]
0x75A1 BlockAdditions [ RFC-to-be; Section 5.1.3.5.2 ]
0x75A2 DiscardPadding [ RFC-to-be; Section 5.1.3.5.7 ]
0x7670 Projection [ RFC-to-be; Section 5.1.4.1.29.41 ]
0x7671 ProjectionType [ RFC-to-be; Section 5.1.4.1.29.42 ]
0x7672 ProjectionPrivate [ RFC-to-be; Section 5.1.4.1.29.43 ]
0x7673 ProjectionPoseYaw [ RFC-to-be; Section 5.1.4.1.29.44 ]
0x7674 ProjectionPosePitch [ RFC-to-be; Section 5.1.4.1.29.45 ]
0x7675 ProjectionPoseRoll [ RFC-to-be; Section 5.1.4.1.29.46 ]
0x78B5 OutputSamplingFrequency [ RFC-to-be; Section 5.1.4.1.30.2 ]
0x7BA9 Title [ RFC-to-be; Section 5.1.2.12 ]
0x7D7B ChannelPositions [ RFC-to-be; Reclaimed in Section 28.26 ]
0x22B59C Language [ RFC-to-be; Section 5.1.4.1.19 ]
0x22B59D LanguageBCP47 [ RFC-to-be; Section 5.1.4.1.20 ]
0x23314F TrackTimestampScale [ RFC-to-be; Section 5.1.4.1.15 ]
0x234E7A DefaultDecodedFieldDuration [ RFC-to-be; Section 5.1.4.1.14 ]
0x2383E3 FrameRate [ RFC-to-be; Reclaimed in Section 28.25 ]
0x23E383 DefaultDuration [ RFC-to-be; Section 5.1.4.1.13 ]
0x258688 CodecName [ RFC-to-be; Section 5.1.4.1.23 ]
0x26B240 CodecDownloadURL [ RFC-to-be; Reclaimed in Section 28.21 ]
0x2AD7B1 TimestampScale [ RFC-to-be; Section 5.1.2.9 ]
0x2EB524 UncompressedFourCC [ RFC-to-be; Section 5.1.4.1.29.15 ]
0x2FB523 GammaValue [ RFC-to-be; Reclaimed in Section 28.24 ]
0x3A9697 CodecSettings [ RFC-to-be; Reclaimed in Section 28.19 ]
0x3B4040 CodecInfoURL [ RFC-to-be; Reclaimed in Section 28.20 ]
0x3C83AB PrevFilename [ RFC-to-be; Section 5.1.2.4 ]
0x3CB923 PrevUUID [ RFC-to-be; Section 5.1.2.3 ]
0x3E83BB NextFilename [ RFC-to-be; Section 5.1.2.6 ]
0x3EB923 NextUUID [ RFC-to-be; Section 5.1.2.5 ]
0x1043A770 Chapters [ RFC-to-be; Section 5.1.7 ]
0x114D9B74 SeekHead [ RFC-to-be; Section 5.1.1 ]
0x1254C367 Tags [ RFC-to-be; Section 5.1.8 ]
0x1549A966 Info [ RFC-to-be; Section 5.1.2 ]
0x1654AE6B Tracks [ RFC-to-be; Section 5.1.4 ]
0x18538067 Segment [ RFC-to-be; Section 5.1 ]
0x1941A469 Attachments [ RFC-to-be; Section 5.1.6 ]
0x1C53BB6B Cues [ RFC-to-be; Section 5.1.5 ]
0x1F43B675 Cluster [ RFC-to-be; Section 5.1.3 ]

Second, a new registry is to be created called the Matroska Chapter Codec IDs registry.

IANA QUESTION --> As before, where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

IANA QUESTION --> What is the registration policy (see RFC8126) for the new Matroska Chapter Codec IDs registry?

There are two initial registrations in the new registry as follows:

Chapter Change
Codec ID Controller Reference
------------+-----------------------+-------------
0 (RESERVED) IETF [ RFC-to-be ]
1 (RESERVED) IETF [ RFC-to-be ]

Third, in the Media Types registry located at:

https://www.iana.org/assignments/media-types/

three, new media types are to be registered as follows:

In the video media types registry:

Name: matroska
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

and

Name: matroska-3d
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

In the audio media types registry:

Name: matroska
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-28):

From: The IESG
To: IETF-Announce
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-matroska@ietf.org, mcr+ietf@sandelman.ca, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Matroska Media Container Format Specifications) to Proposed Standard


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'Matroska Media Container Format Specifications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-02-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the Matroska audiovisual container, including
  definitions of its structural elements, as well as its terminology,
  vocabulary, and application.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-matroska-13
This version is dated 4 July 2022.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The WG is very small (6-8 active participants), so there aren't a lot of
people other than the three authors.  OTH, pretty much the entire active part
of the WG was involved in the consensus for this document.

> Was there controversy about particular points, or were there decisions where
> the consensus was particularly rough?

No, the document went through with a notable absense of drame.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document?

Yes.  The document represents codification of 20 years of implementation
experience.  Notable implementations include vlc, ffmpeg.

>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

Pretty much all the relevant people are at the IETF WG.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such content as MIG or YANG is present.
A media type review occured.

> If the document contains a YANG module, has the final version of the module

No YANG module.

>Describe reviews and automated checks performed to validate sections of the
>final version of the document written in a formal language, such as XML code,
>BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

Yes.  Document shepherd did a full top-to-bottom review which resulted in
some significant format and text layout changes, but not technical changes.

> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been identified
> and addressed? For which does this still need to happen in subsequent
> reviews?

No.

> What type of RFC publication is being requested on the IETF stream (Best
> Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper type
> of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard is approriate for this document.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? To
> the best of your knowledge, have all required disclosures been filed? If
> not, explain why. If yes, summarize any relevant discussion, including links
> to publicly-available messages when applicable.

Document authors have disclosed.

> Has each author, editor, and contributor shown their willingness to be
> listed as such? If the total number of authors and editors on the front page
> is greater than five, please provide a justification.

Document authors have agreed.

> Document any remaining I-D nits in this document. Simply running the idnits
> tool is not enough; please review the "Content Guidelines" on
> authors.ietf.org. (Also note that the current idnits tool generates
> some incorrect warnings; a rewrite is underway.)

This was done.

> Should any informative references be normative or vice-versa? See the IESG
> Statement on Normative and Informative References.

A review was done and some changes were made.

> List any normative references that are not freely available to anyone. Did
> the community have sufficient access to review any such normative
> references?

Yes.  One ISO standard (country codes) is not available, but mostly nobody
cares to read the list.

> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so,
> list them.

No.

> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear state?
> If so, what is the plan for their completion?

There are two reference to WG documents, which the WG is working on sorting out if they need
to be normative.

> Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert clear?
> Please include suggestions of designated experts, if appropriate.

Yes.

Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-matroska-13
This version is dated 4 July 2022.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The WG is very small (6-8 active participants), so there aren't a lot of
people other than the three authors.  OTH, pretty much the entire active part
of the WG was involved in the consensus for this document.

> Was there controversy about particular points, or were there decisions where
> the consensus was particularly rough?

No, the document went through with a notable absense of drame.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document?

Yes.  The document represents codification of 20 years of implementation
experience.  Notable implementations include vlc, ffmpeg.

>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

Pretty much all the relevant people are at the IETF WG.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such content as MIG or YANG is present.
A media type review occured.

> If the document contains a YANG module, has the final version of the module

No YANG module.

>Describe reviews and automated checks performed to validate sections of the
>final version of the document written in a formal language, such as XML code,
>BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

Yes.  Document shepherd did a full top-to-bottom review which resulted in
some significant format and text layout changes, but not technical changes.

> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been identified
> and addressed? For which does this still need to happen in subsequent
> reviews?

No.

> What type of RFC publication is being requested on the IETF stream (Best
> Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper type
> of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard is approriate for this document.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? To
> the best of your knowledge, have all required disclosures been filed? If
> not, explain why. If yes, summarize any relevant discussion, including links
> to publicly-available messages when applicable.

Document authors have disclosed.

> Has each author, editor, and contributor shown their willingness to be
> listed as such? If the total number of authors and editors on the front page
> is greater than five, please provide a justification.

Document authors have agreed.

> Document any remaining I-D nits in this document. Simply running the idnits
> tool is not enough; please review the "Content Guidelines" on
> authors.ietf.org. (Also note that the current idnits tool generates
> some incorrect warnings; a rewrite is underway.)

This was done.

> Should any informative references be normative or vice-versa? See the IESG
> Statement on Normative and Informative References.

A review was done and some changes were made.

> List any normative references that are not freely available to anyone. Did
> the community have sufficient access to review any such normative
> references?

Yes.  One ISO standard (country codes) is not available, but mostly nobody
cares to read the list.

> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so,
> list them.

No.

> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear state?
> If so, what is the plan for their completion?

There are two reference to WG documents, which the WG is working on sorting out if they need
to be normative.

> Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert clear?
> Please include suggestions of designated experts, if appropriate.

Yes.