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

[Steve Lhomme <[e-mail]>]

Hi Andy,

Thanks for your review. My comments are inline below.

> On 6 Jan 2026, at 18:46, Andy Newton via Datatracker <[e-mail]> wrote:
> 
> Andy Newton 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:
> ----------------------------------------------------------------------
> 
> # Andy Newton, ART AD, comments for draft-ietf-cellar-tags-20
> CC @anewton1998
> 
> * line numbers:
>  -
>  https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cellar-tags-20.txt&submitcheck=True
> 
> * comment syntax:
>  - https://github.com/mnot/ietf-comments/blob/main/format.md
> 
> * "Handling Ballot Positions":
>  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> ## Thanks to the Reviewers
> 
> I want to thank the many reviewers of this draft, particularly Sean Turner for
> his ARTART review.
> 
> ## Discuss
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
> a DISCUSS ballot is just a request to have a discussion on the following topics.
> 
> ### UTF-8 and Problematic Code Points.
> 
> 196        Official TagName values MUST consist of UTF-8 capital letters,
> 197        numbers and the underscore character '_'.
> 
> In addition to Roman's DISCUSS on capitalized UTF-8, should the tags be
> limited to exclude the problematic code points as described in RFC 9839?

Because there’s no proper definition of capital letters, I’m more inclined to limit to the latin capital letters. That basically turns the TagName element into an ASCII (“string" type) element rather than UTF-8 element, without breaking backward compatibility. https://www.rfc-editor.org/rfc/rfc9559#name-tagname-element

As for the problematic code points, it seems that it’s rather a more general problem for all Matroska UTF-8 elements or even EBML in general.

> And from your Security Considerations sections:
> 
> 1671       Most of the time strings are kept as-is and don't pose a security
> 1672       issue, apart from invalid UTF-8 values.  Implementations MUST
> 1673       validate TagString inputs for UTF-8 correctness and reasonable length
> 1674       before use, in accordance with the security considerations in
> 1675       Section 10 of [RFC3629].
> 
> I think you have to apply RFC 9839 to make a statement that UTF-8 values
> don't apply a security risk.

Not being a UTF-8 or security experts, I’d rather stick with the Security Considerations of the  RFC that defines UTF-8. 

> ### Beginning Underscore
> 
> 204        It is RECOMMENDED that tag names start with the underscore character
> 205        '_' for non official tags that are not meant to be added to the list
> 206        of official tags.
> 
> Why is the RECOMMENDED? Can it be a MUST? If it is RECOMMENDED, what are the
> ramifications of not following the recommendation?

Because there are tons of files out there with custom tag names (I mentioned FFmpeg and mkvtoolnix in another review) that don’t follow this rule. This rule has been added more recently so we have an official way to define tags that are private.

> ### TagString Formatting
> 
> 215        Multiple items SHOULD NOT be stored as a list in a single TagString.
> 216        If there is more than one tag value with the same name to be stored,
> 217        it is RECOMMENDED to use separate SimpleTags with that name for each
> 218        value.
> 
> Can this be a MUST NOT? Why allow them to be stored as a list at all. And if
> this advice is not followed, what happens? Is it that some software won't
> interoperate? If that is the case, I think you are better off stating this as a
> MUST NOT.

As mentioned in Éric’s review:
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/ 

Especially since INSTRUMENTS and KEYWORDS suggest they can group multiple values separated by a comma.


> 220        Preexisting files may have used multiple values in the same TagString
> 221        but given there is no defined delimiters they cannot be easily split
> 222        into multiple elements.  INSTRUMENTS (Section 4.4) and KEYWORDS
> 223        (Section 4.6) tags allow using a comma as a separator.  However, it
> 224        is RECOMMENDED to use separate SimpleTags with each containing a
> 225        single instrument or keyword value, respectively.
> 
> Why are separate tags only RECOMMENDED? Can this be a MUST as well? If it is to
> remain as a RECOMMENDED, what are the consequences of not following the
> recommendation?

Precisely because of preexisting files. We cannot make them invalid just because now we want stricter rules.

There is no consequence to grouping or not grouping elements. Matroska Readers should be able to group values (or keep them split) in any case as it has always been an option. As with a database it’s better if you use atomic values that can be referenced multiple times.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## Comments
> 
> ### Support Of Other DISCUSS Positions
> 
> I support Éric's DISCUSS on UTF-8 spaces. Should that be whitespace?
> 
> I support Gory's position on the "Official". IMHO, the doc is describing
> "registered" values, not "official" values.
> 
> And like Gory, I support Med's position on the specification required for DEs.
> 
> 
>