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

[Robert Sparks <[e-mail]>]

Hi Steve - I'll work with you directly to resolve this.

RjS

On 8/26/25 8:55 AM, Steve Lhomme wrote:
> I just tried but I cannot login to the IETF website. It requires a new 
> password because the old one was too short. But I never get the email 
> to reset my password.
>
> I'll wait, maybe it's taking time. Hopefully it will let me log in 
> tonight...
>
> Steve
>
> On 8/25/2025 5:26 PM, Spencer Dawkins at IETF wrote:
>> Hi, Steve,
>>
>> On Sun, Aug 24, 2025 at 2:39 AM Steve Lhomme <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     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.
>>
>>
>> Yes, please! That will allow Orie to start IETF Last Call, the next 
>> step in the process.
>>
>> Best,
>>
>> Spencer
>>
>>
>>     Steve
>>
>>>     On 14 Aug 2025, at 23:21, Orie <[e-mail]
>>>     <mailto:[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
>>> <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/ <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 usinghttps://datatracker.ietf.org/wg/precis/
>>>>>             documents/ <https://datatracker.ietf.org/wg/precis/
>>>>> documents/>orhttps://datatracker.ietf.org/doc/draft-
>>>>>             bray-unichars/ <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 <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
>>>
>>
>>     _______________________________________________
>>     Cellar mailing list -- [e-mail] <mailto:[e-mail]>
>>     To unsubscribe send an email to [e-mail]
>>     <mailto:[e-mail]>
>>
>