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

[Steve Lhomme <[e-mail]>]

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