[Cellar] Re: Éric Vyncke's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Steve,

Thanks for your 2 messages (and your patience).

Replying to the first one (to be simple). See inline for EV>

In short, please merge the PRs and submit a revised I-D, then I am clearing my DISCUSS.

Regards,

-éric


From: Steve Lhomme <[e-mail]>
Date: Sunday, 11 January 2026 at 11:45
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)

Hi Eric and thanks for your review,

My comments are inline below.

On 5 Jan 2026, at 09:46, Éric Vyncke via Datatracker <[e-mail]> wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-cellar-tags-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-cellar-tags-20
CC @evyncke

Thank you for the work put into this document even if I find a little weird to
have tag definitions of a container done in a codec WG, but it fits the CELLAR
WG charter, so all is good.

What is now RFC9559 originally had the tags and codec definition into a single document (and even some other things). We split in the document so we can work on the main one faster.

EV> thanks for the added piece of information
Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Spencer Dawkins for the shepherd's detailed write-up
including the WG consensus (albeit a small WG it seems) and the justification
of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Missing version

The CELLAR charter includes `Standards Track specification for Matroska
container format version 4` but this I-D, while proposed standard, does not
mention at all the version 4. So, it is really unclear.

Note: RFC 9559 section 7 is about versioning, but this I-D should really
mention version 4.

The tags document define the values set in Matroska elements \Segment\Tags\Tag\+SimpleTag\TagName, \Segment\Tags\Tag\+SimpleTag\TagString and \Segment\Tags\Tag\+SimpleTag\TagBinary.
The elements don’t have a “minver” attribute, which means they are usable since Matroska v1. That’s why there is no versioning mentioned.
All the tags, even the ones that don’t exist yet and even “unofficial” ones, can be used in files compatible with Matroska v1. For apps that interpret tags, they only need to handle the names they care about and ignore the (infinite) rest.

EV> ah ah... it there any chance to add some text like the above in the introduction ?
### Section 3.2.1

Happy to be corrected as I am not a UTF-8 expert, but what is the exact
definition of `any space`? again thinking about UTF-8 and
https://en.wikipedia.org/wiki/Whitespace_character

A similar question was raised about capital letters as there’s no proper rule to define what is UTF-8/Unicode capital letter (I can find the post anymore).
I can add a link to the wikipedia page if that helps. Now that these recommendations are a MUST we could also remove this line altogether, since it’s not part of the allowed characters that MUST be used.

EV> I have read that other ADs had the same comments and that a PR is on its way. Please merge and re-submit.
### Section 4.11

`Library of Congress Control Number` but from which country? This definition is
ambiguous.

Addressed here https://github.com/ietf-wg-cellar/matroska-specification/pull/1051


EV> looks good to me

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Support for others DISCUSS points

I second (hence won't repeat) the following DISCUSS points by Med:
- use of BCP14 in IANA considerations
- other issues mentioned in the IANA considerations

I note though that IANA tagged (punt intended) this I-D as "IANA OK"

### Abstract

Abstracts need to be concise but also useful and descriptive. I.e., at least
mention the version (per my DISCUSS point) and be more descriptive.

The title should also include "version 4".

No, these tags are usable in all Matroska versions. There is no versioning of tag names and values.

EV> see above
### Section 1

Please expand `EBML` at first use.

What do you mean by “expand” ? There is a link to the "Section 7.7 of [RFC8794]” in the first sentence where it’s used.

EV> ouch, my bad then
### Use of personal pronouns

Let's avoid the use of personal pronouns such as `if you wanted to store`
(section 3) or `We also need an official list` (section 3.1) or even `Our
recommendations are in between` and `put any tag in your file` (section 3.1
albeit not pronouns ;-) ). I.e., who is the "we" ? The authors ? The WG ? The
IETF ?

Addressed by https://github.com/ietf-wg-cellar/matroska-specification/pull/1052

EV> thanks
### Use of 'official'

As noted in other ballots, please refrain using `official`, the IETF issues
standards and not laws; so, s/official/standard/ would be much better.

Addressed by https://github.com/ietf-wg-cellar/matroska-specification/pull/1048

EV> thanks
### Section 3.2.1

`UTF-8 capital letters`, I am not a UTF-8 or internationalisation expert, but
do all alphabets have "capital letters" (and should it be "character" rather
than `letter`)

There is no clear definition of UTF-8 capital letters nor a nice rule to apply.

That could be problem if someone proposes tag names in some language that don’t have capital letters (chinese ? japanese ?). No sure what to do here. We cannot change the “TagName" type from UTF-8 to ASCII anymore. Maybe we could say only latin capital letters ? A lot of languages have a latinized version.

EV> I have read that other ADs had the same comments and that a PR is on its way. Please merge and re-submit.

### Section 3.2.2

Why not a MUST in `Multiple items SHOULD NOT`? See also
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

This used to be that way but turned back in https://github.com/ietf-wg-cellar/matroska-specification/pull/1030
After the AD review from Orie https://mailarchive.ietf.org/arch/msg/cellar/4ebLFttRb_I8SFu5yMQSIDPuk2E/

EV> the guidance for the SHOULD should still be there though...
### Section 3.2.2.2

A long discussion about the decimal '.' vs. ',', but nothing is written in
which base the "UTF-8 number" is represented. I guess base 10, but let's be
specific. I also wonder why not using a IEEE binary format was not used
(possibly for backward compatibility).

These tag values often correspond to tags found in other systems like ID3 where they are stored as strings. So for compatibility with other systems we use strings as well. Newer binary formats like the EBU R128 are stored as binary.

I added some text to mention it’s in base 10 in https://github.com/ietf-wg-cellar/matroska-specification/pull/1053

### Section 3.3.1

Should there be a definition or reference for `TagChapterUID`? (also for other
*UID terms).

I added some text mentioning the ChapterUID which value is used in https://github.com/ietf-wg-cellar/matroska-specification/pull/1054

Thanks again for your review.
Steve