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

[Steve Lhomme <[e-mail]>]

Hi Éric and everyone,

I added a new Pull Request to restrict the range of characters in TagName even further. Rather than “UTF-8 capital letters” which is vague and doesn’t really exist as such, it’s now A-Z only letters.

This capital rule, that turned into a UTF-8 capital rule, was really meant to limit to a simple set anyway, back when emojis didn’t exist (I think).

I also added an ABNF notation to make sure there is no confusion and can be easily parsed:
https://github.com/ietf-wg-cellar/matroska-specification/pull/1065

Best regards,
Steve

> On 11 Jan 2026, at 11:44, Steve Lhomme <[e-mail]> wrote:
> 
> 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.
> 
>> 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.
> 
>> ### 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.
> 
>> ### 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 
> 
>> ----------------------------------------------------------------------
>> 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.
> 
>> ### 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.
> 
>> ### 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 
> 
>> ### 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 
> 
>> ### 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.
> 
>> ### 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/ 
> 
>> ### 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