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

[Steve Lhomme <[e-mail]>]

Hi Roman and everyone,

I added a new Pull Request to restrict the range of characters in TagName even further. Rather than “UTF-8 capital letters” which is vague and doesn’t really exist as such, it’s now A-Z only letters.

This capital rule, that turned into a UTF-8 capital rule, was really meant to limit to a simple set anyway, back when emojis didn’t exist (I think).

I also added an ABNF notation to make sure there is no confusion and can be easily parsed:
https://github.com/ietf-wg-cellar/matroska-specification/pull/1065

Best regards,
Steve

> On 11 Jan 2026, at 12:21, Steve Lhomme <[e-mail]> wrote:
> 
> Hi Roman,
> 
> Thanks for your review. My comments are inline below.
> 
>> On 5 Jan 2026, at 18:33, Roman Danyliw via Datatracker <[e-mail]> wrote:
>> 
>> Roman Danyliw 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:
>> ----------------------------------------------------------------------
>> 
>> **  Section 3.2.1
>>   Official TagName values MUST consist of UTF-8 capital letters,
>>   numbers and the underscore character '_'.
>> 
>> What is definition of “UTF-8 capital letters”?
> 
> There is no proper UTF-8 definition for that. See my answer to Éric’s review https://mailarchive.ietf.org/arch/msg/cellar/6la3CAjSVA1w-P0HA8yJx2YPb6Y/
> 
> "That could be problem if someone proposes tag names in some language that don’t have capital letters (chinese ? japanese ?). No sure what to do here. We cannot change the “TagName" type from UTF-8 to ASCII anymore. Maybe we could say only latin capital letters ? A lot of languages have a latinized version.”
> 
> 
>> ** What is the format for an “official TagName”
>> 
>> -- Section 3.2.1 say “Official TagName values MUST consist of UTF-8 capital
>> letters,    numbers and the underscore character '_'.”
>> 
>> -- Section 6.1 says “The Name corresponds to the value stored in the TagName
>> element.  The Name SHOULD always be written in all capital letters and contain
>> no space as defined in Section 3.2,”
>> 
>> The text in Section 6.1 suggests weaker conformance to only “capital letters”
>> is required.
> 
> Indeed, they should have the same requirement. Addressed in https://github.com/ietf-wg-cellar/matroska-specification/pull/1056 
> 
>> ** Section 3.2.2.2
>>   In legacy media containers, it is possible that the "," character
>>   might have been used as a separator or that digit grouping delimiters
>>   might have been used.  A Matroska Reader SHOULD consider the
>>   following character handling to parse such legacy formats:
>> 
>> How does an implementation know it is processing a “legacy media container” to
>> apply these alternative parsing rules?
> 
> If you know the tag is a Number you can parse it as a number and assume a single , corresponds to a decimal separator. But there is no guarantee and no real way to tell.
> 
> The rules have been made stricter since the original Matroska specifications, so that parsing can be made more strict. So new software writing tags from other sources should try to do the conversion to a stricter format. But readers should be aware there may be older formats. They choose what to do with these uncertain values.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thank you to Ines Robles for the GENART review.
>> 
>> I support the DISCUSS position of Mohamed Boucadair, Gorry Fairhurst, and Éric
>> Vyncke.
>> 
>> ** Section 3.1
>>   There is a debate between people who think all tags should be free
>>   and those who think all tags should be strict.  Our recommendations
>>   are in between.
>> 
>> -- “Our recommendations”, is this the opinion of the WG or the authors?
> 
> Addressed in https://github.com/ietf-wg-cellar/matroska-specification/pull/1052
> 
>> -- I found the terms “free” and “strict” confusing.  Is this “free-form” as
>> opposed to being without cost?  “Strict” relative to what?
> 
> Yes, it’s free-form. I proposed a new wording in https://github.com/ietf-wg-cellar/matroska-specification/pull/1057
> 
> “There is a debate between people who think all tags should be free-form and those who think
> all tags should be limited to a set of names."
> 
>> ** Section 3.1
>>   Both have their needs, but it's usually a
>>   bad idea to use custom or exotic tags because you will probably be
>>   the only person to use this information even though everyone else
>>   could benefit from it.
>> 
>> Why using “custom or exotic tags” is a “bad idea” would benefit from more
>> explanation.  The negative implications of low use tags is not clear.
> 
> “you will probably be the only person to use this information even though everyone else could benefit from it"
> Seems to me like a very good reason not to go that way.
> 
>> ** Section 3.1
>>   So hopefully, when someone wants to put
>>   information in one's file, they will find an official one that fits
>>   their need and hopefully use it.
>> 
>> What makes a tag “official”?
> 
> Assigned a name in the IANA registry.
> 
>> ** Section 3.1
>>   It's hard to define what should be in and
>>   what ought not be in a file because it doesn't make sense; thus, each
>>   request needs to be evaluated to determine if it makes sense to be
>>   carried over in a file for storage and/or sharing or if it doesn't
>>   belong there.
>> 
>> It is unclear how a reader should take action on this assessment.
> 
> That’s why it says it’s “hard to define”. And two persons might not even agree what metadata should be in a file and what should not.
> 
> For example I could propose a tag “HAS_SET_FOOT_IN_ROUBAIX”. It could make it in the ~official~assigned list. But no one would really use it. But if some people what to put that information in their file, why not. But that should rather qualify for tags that start with an underscore for private use.
> 
>> ** Section 3.2.1
>>   Official TagName values MUST NOT contain any space.
>> 
>> Is this the same as saying must not contain “space characters”?
> 
> Yes, although we may get rid of that line since we already have a set of characters that can be used.
> 
>> ** Section 3.3.  Table 1 and 2.
>>   | 70              | COLLECTION      | the high hierarchy consisting |
>>   |                 |                 | of many different lower items |
>> What is a “high hierarchy”?  Does this mean the highest element in a hierarchy
>> of elements?
> 
> No as someone could come up with even higher values than 70 for an even more set of “COLLECTION”, and even higher values of a set of these sets, etc.
> 
> If anyone has a better (concise) way to describe a COLLECTION of items, I can make the change.  
> 
>> ** Section 4
>> 
>> 4.  Official Tags
>> 
>>   The following is a complete list of the supported Matroska Tags.  As
>> 
>> What is being implied by “supported”?  Supported by what?
> 
> Addressed in https://github.com/ietf-wg-cellar/matroska-specification/pull/1049
> “The following is the initial list of assigned Matroska Tags."
> 
>> ** Section 4.5.  Table 7.
>> 
>> Consider if further specificity in the format of the FAX and PHONE is needed
>> and would be helpful.  E.164 specifies the 15-digit country code + national
>> destination code + subscriber number format.
>> 
>> [E.164] ITU Telecommunication Standardization Sector, "The International Public
>> Telecommunication Numbering Plan", ITU-T Recommendation E.164, November 2010.
> 
> We never put a formal format for this. So as with demical numbers, forcing a fixed format now means we also have to describe all the other ways that the numbers may have been stored. But I don’t think we can come up with such a list.
> 
> For this kind of thing it’s probably bettter to define a new tag name like PHONE_E164 with a strict format.