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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Eric,

I am following up on your note asking Stephen to merge PRs and submit a new
revision - the PRs are merged in -22.

Please consider clearing your DISCUSS.

Best,

Spencer

On Sun, Feb 22, 2026 at 11:08 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> 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
>