[Cellar] Re: AD Evaluation: draft-ietf-cellar-tags-18

[Steve Lhomme <[e-mail]>]

Hi Orie,

I merged the last pending change. Should I publish a draft-ietf-cellar-tags-19 with it ? That might be want we send to the RFC Editors in the forthcoming steps.

Steve

> On 14 Aug 2025, at 23:21, Orie <[e-mail]> wrote:
> 
> Hi Steve & Cellar,
> 
> Sorry for the delay in replying to your note.
> 
> The note about unichars was just a comment (non blocking feedback), in case it was useful.
> 
> This PR remains open:
> 
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1020
> 
> As far as I can tell you have addressed the rest of my comments.
> 
> Regards,
> 
> OS, ART AD
> 
> 
> 
> On Sun, Jul 20, 2025 at 8:08 AM Steve Lhomme <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi,
>> 
>> Limiting commits to a subject that needs to be addressed in here.
>> 
>>> On 7 Jul 2025, at 18:27, Orie <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Steve & Cellar,
>>> 
>>> Inline replies prefixed with OS, sorry to have not gotten you this feedback in time for the draft cut off.
>>> 
>>> Unless noted, you can assume I have no objection to your comments, but please point out if you are expecting a specific response from me.
>>> 
>>> On Sun, Jun 29, 2025 at 5:55 AM Steve Lhomme <[e-mail] <mailto:[e-mail]>> wrote:
>>>> Hi Orie,
>>>> 
>>>> Thanks a lot for your detailed review. I’ll add comments and some Merge Requests with fixes where possible.
>>>> 
>>>>> On 20 Jun 2025, at 22:54, Orie <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>>> ### UTF-8 "letters"
>>>>> 
>>>>> ```
>>>>> 195   Official TagName values MUST consist of UTF-8 capital letters,
>>>>> 196   numbers and the underscore character '_'.
>>>>> 
>>>>> 198   Official TagName values MUST NOT contain any space.
>>>>> 
>>>>> 200   Official TagName values MUST NOT start with the underscore character
>>>>> 201   '_'; see Section 3.1.
>>>>> ```
>>>>> 
>>>>> ABNF might be helpful for this.
>>>> 
>>>> That would definitely be useful. However there doesn’t seem to be any logic for UTF-8 upper (or lower) case values, or even simply letters, as opposed to symbols.
>>>> 
>>>> Looking at RFC 5234 (ABNF) it doesn’t really take in account Unicode but rather defined bits when it’s not ASCII (RFC 3629 - UTF-8 has a binary ABNF definition).
>>>> 
>>>> I can a name to describe a UTF-8 upper letter and then do the rest of the ABFN with that. But I don’t think that’s valid.
>>> 
>>> OS: Consider if this is helpful: https://datatracker.ietf.org/doc/draft-bray-unichars/  (for defining the repertoire you are expecting software to recognize)
>>> 
>>>> 
>>>>> 
>>>> 
>>>>> ### Type UTF-8
>>>>> 
>>>>> ```
>>>>> 824       | SUBTITLE | UTF-8 | Sub Title of the entity.  This is     |
>>>>> ```
>>>>> 
>>>>> Are emoji allowed? what about control characters?
>>>> 
>>>> Any UTF-8 character. This is stored in a binary format that doesn’t need escaping. So any valid UTF-8 value is fine.
>>>> 
>>>>> Is there a more specific way to describe this type?
>>>>> 
>>>>> Consider using https://datatracker.ietf.org/wg/precis/documents/ or https://datatracker.ietf.org/doc/draft-bray-unichars/ .
>>>> 
>>>> Not sure what you are proposing here. The value is anything that is a valid UTF-8 string. The meaning is a “sub title”. Maybe “under title” is better or there are more appropriate word in English ? 
>>>> It seems that “subtitle” is commonly used for that https://www.writeitgreat.com/post/title-vs-subtitle-what-s-the-difference
>>>> 
>>>> In the linked ID3 tag, the definition is “Subtitle/Description refinement”.
>>> 
>>> OS: See comment about repertoires above, please read the reference and consider if an attacker might abuse the ability to inject arbitrary unicode.
>> 
>> If I understand correctly the concern is that UTF-8 allows more than displayable characters and can even contain ill-formed data.
>> 
>> We can probably limit the tag name and the tag values to the “non problematic” values, so the ones described in "4.3.  Unicode Assignables”. But we should also do that for Unicode strings in EBML and in Matroska. Limiting the values in the tags document would be inconsistent with the Document that document defines these elements as UTF-8 values, ie RFC9559. Given this is defining the “official values” that should be used, we may impose extra rules compared to the raw/any UTF-8 allowed by the format. It may also be part of a guideline. However it cannot be a MUST because we don’t know what people have put in these elements so far. If the UTF-8 is correct, then there’s no reason to make it invalid because it’s considered problematic now.
>> 
>> Which leads me to the other point. I would be willing to use a reference to the Unicode Assignables section as the basis for our rules. But that document is not yet published. I may use their ABNF but it may also be bogus or might be extended until it’s published. So using this document as a reference would delay the publication of the tags spec until that document eventually is published (if ever) ?
>> 
>> Steve