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

[Andy Newton <[e-mail]>]

On 1/11/26 7:20 AM, Steve Lhomme wrote:
>> ### 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.

Ok. You sidestep the problematic code points if you limit it to upper-case latin.

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

The problem is that you say the strings "don't pose a security risk", except 9839 discusses why they can. IMO, you can't make that claim without accounting for problematic code points.

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

Ok. That makes sense. Thanks.

> 
>> ### 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 <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/ <https://mailarchive.ietf.org/arch/msg/cellar/4ebLFttRb_I8SFu5yMQSIDPuk2E/> 
> 
> Especially since INSTRUMENTS and KEYWORDS suggest they can group multiple values separated by a comma.

Ok. If this was previously discussed then I won't belabor it. 

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

I see this was also part of the previously discussed item as well. Again, let's go with the current resolution.

-andy