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

[Steve Lhomme <[e-mail]>]

Hello Mike,

To address your remark on the 3.2.1 section I propose this Pull Request: https://github.com/ietf-wg-cellar/matroska-specification/pull/1076
With the following text added to 3.2.1:

The `TagName` element can hold any UTF-8 data. However, to distinguish between the IANA assigned names and custom or private ones, a set of rules are defined.

Would that be clear enough ? Basically the rule of naming only applies to names that may end up in the IANA registry. All other names are OK as well, but if they don’t follow the rules they can’t be added in the IANA registry.

> On 25 Feb 2026, at 05:26, Mike Bishop <[e-mail]> wrote:
> 
> I'm sorry about the delay; this fell off my radar. Spencer has helpfully flagged it just as I'm recovering from vacation. I've taken a look at -22, and I'm content to clear the DISCUSS, though I still have one comment you might consider. I'll pull it to the top here, and have updated my ballot with the same.
> 
> I think Section 3.2.1's scope needs to be clarified. As currently written, it restricts the format of "Assigned TagName values," i.e. those that are going in the registry; hence my suggestion that a completely non-conformant tag might still be considered valid but unregisterable. But your response below suggests you expect these restrictions to be enforced even for private-use tags. I would encourage you to clearly distinguish what is a syntactically valid tag (even if it cannot be registered/assigned); that may already exist in other specifications, and a pointer would be sufficient.
> 
> 
> From: Steve Lhomme <[e-mail]>
> Sent: Sunday, January 18, 2026 6:02 AM
> To: Mike Bishop <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: Mike Bishop's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)
> 
> Hello Mike,
> 
> Thanks for your follow-up review. My comments are below. I assume your only answers are the ones with [MB] in the front. Let me know if I missed anything.
> 
> On 13 Jan 2026, at 23:13, Mike Bishop <[e-mail]> wrote:
> 
> Some comments inline with [MB].
> 
> From: Steve Lhomme <[e-mail] <mailto:[e-mail]>>
> Sent: Sunday, January 11, 2026 8:53 AM
> To: Mike Bishop <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
> Subject: Re: Mike Bishop's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)
>  
> Hi Mike,
> 
> Thanks a lot for your review. My comments are inline below.
> 
> On 6 Jan 2026, at 20:13, Mike Bishop via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Mike Bishop 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:
> ----------------------------------------------------------------------
> 
> # IESG review of draft-ietf-cellar-tags-20
> 
> CC @MikeBishop
> 
> ## Discuss
> 
> ### Focus on interoperability
> 
> Throughout the draft, but especially in Section 3.1, there are justifications
> given for the use of "Official" tags. Setting that term aside, there's a word
> for this problem:
> 
> 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
> 
> It's called lack of interoperability. Rephrasing all of this to talk about
> 
> That’s is indeed a much better and precise word.
> 
> optimizing for interoperable use of tags would help. For example, in Section 3.1
> consider:
> 
>   An application intended for advanced users might permit the insertion of any
>   tag in a file. While this provides maximum flexibility, custom or exotic tags
>   generally limit interoperable use.  Well-known tags improve the ability of
>   others to read and reuse them; most applications will therefore use a small
>   list of useful tags.
> 
> I replaced part of that long paragraph with your text: https://github.com/ietf-wg-cellar/matroska-specification/pull/1058
> 
> [MB] Looks good.
> 
> Applied for the next draft.
> ### What is "official"?
> 
> I share others' issues with the term "Official". Enough has been said at enough
> length, I think.
> 
> It should be “assigned” instead as in https://github.com/ietf-wg-cellar/matroska-specification/pull/1048
> 
> [MB] That's a better term, yes.
> 
> Applied for the next draft.
> ### Section 3.2.1, paragraph 1
> 
> These are the requirements for a TagName to be registered; focus on the
> registration. This might be good guidance for a Designated Expert.
> 
> The IANA section also references this with more consistency using https://github.com/ietf-wg-cellar/matroska-specification/pull/1056
> 
> [MB] I think the pieces to separate are:
> What is a syntactically valid tag? If my tag is "🤑🤷‍♂️   Cool story", but I'm not attempting to register it, that's fully compliant with the current text of 3.2.1. (Because I'm not attempting to register it, so the three MUST statements don't attach; the fourth is a RECOMMENDED, so it's not mandatory.) 3.2.1 should focus on syntactic validity.
> 
> If a tag name starts with _ it’s a signal that it is knowingly not meant to be used broadly. i.e., for internal use by an organisation or a program. And that there will be no attempt to make it more officially defined.
> This recommendation is rather new (2022) https://github.com/ietf-wg-cellar/matroska-specification/pull/605/files 
> 
> There is already a rule that says a tag name must not start with an underscore (that was introduced to differentiate with unofficial/unassigned tags). So the recommendation is a bit redundant. However it can avoid collisions with a future assigned name that would not have the underscore at the start. So I think it’s a useful recommendation for private use names.
> 
> Because of the nature of tags and multiple heterogeneous sources, there is very likely tag names that follow all the MUST and are not “official”. We are dealing with an existing base we had no control about. In the case of "🤑🤷‍♂️   Cool story”, it’s not following the MUST of Section 3.2.1 so it’s not valid even for private use. Some program that check the content validity may discard the tag as bogus/damaged and skip/lose it it.
> 
> The rule on capital letters only has been in place forever: https://web.archive.org/web/20120505004011/http://matroska.org/technical/specs/tagging/index.html 
> 
> What tags will be accepted in the registry? If IANA is directed only to register / not to register a certain subset of the tag space, such as saying that registration of tags that begin with an underscore will not be permitted, that belongs in the IANA considerations.
> 
> I repeated the rules on tag names in the IANA registration in https://github.com/ietf-wg-cellar/matroska-specification/pull/1056 to match what is defined in 3.2.1
> ### IANA
> 
> This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
> so we can determine next steps during the telechat.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## Comments
> 
> ### Section 3.1
> This section could use significant reworking, both for tone and style.
> 
> ```
>     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.
> ```
> 
> First, you're inviting the "free as in beer / free as in speech" question, when
> you actually mean neither -- I believe you actually mean "free-form".
> 
> Yes. See https://github.com/ietf-wg-cellar/matroska-specification/pull/1057
> 
> [MB] Looks good.
> 
> Second, RFCs should generally avoid the first-person. Maybe "This document's"?
> Consider removing the first/second-person usage throughout the document.
> 
> Yes, this have been changed in https://github.com/ietf-wg-cellar/matroska-specification/pull/1052
> 
> [MB] That addresses three instances, but the document is filled with second-person.
> 
> There has been other reviews with similar issues that have been addressed as well. I think we removed all of such instances. That will be reflected on the next draft.
> 
> You can be much more brief about the ability to register new
> tags. For example:
> 
>   New tags can be added to the Matroska Tags Names registry (Section 6.1).
>   However, this registry is not meant to have every possible piece of
>   information; many attributes would be better stored on a website and
>   retrieved using an identifier for the content.
> 
> The discussion of which new tags might not be appropriate seems more geared to a
> Designated Expert than to someone attempting to implement the specification.
> Consider moving that elsewhere.
> 
> For the more generic tag names, because it’s free-form and we have a ton of legacy values, I think First Come First Served is the preferred policy.
> 
> [MB] That's reasonable, assuming your registration requirements are crisp enough that IANA can enforce them without consultation.
> 
> The underscore rule is added in the IANA registry by https://github.com/ietf-wg-cellar/matroska-specification/pull/1056 
> I added some more text to also note that the underscore character cannot be at the start.
> ### Section 3.2.2, paragraph 1
> ```
>     should be used so everyone can agree on how to use the value.
> ```
> ...so as to improve interoperability.
> 
> Added to https://github.com/ietf-wg-cellar/matroska-specification/pull/1058 
> 
> ### Section 3.2.2.2, paragraph 3
> 
> "Consider" is not an interoperability requirement. This is the behavior
> that a reader SHOULD (or MAY) employ to handle such legacy tags.
> 
> Indeed, I fixed the word in https://github.com/ietf-wg-cellar/matroska-specification/pull/1059
> “A `Matroska Reader` **SHOULD** use the following character handling to parse such legacy formats"
> 
> [MB] Looks good.
> 
> Applied for the next draft.
> ### Section 3.3, paragraph 7
> 
> This can be condensed; consider:
> 
>   This means that if an album has the same artist for all tracks, the "ARTIST"
>   tag with TargetTypeValue 50 (ALBUM) is sufficient. It is not necessary to
>   repeat the value for each track with TargetTypeValue 30 (TRACK) unless there
>   are exceptions. If some tracks of that album have no known "ARTIST", the
>   value MUST be set to an empty string ("") as detailed in Section 24.2 of
>   [RFC9559], so that the album "ARTIST" doesn't apply.
> 
> It is actually longer than the original. Also that means we would need even more text to define the exceptions.
> 
> [MB] So it is -- sorry.
> 
> ### Section 3.3, paragraph 8
> 
> Or below? Presumably stopping a value at one level also cascades.
> 
> From the rule in the previous paragraph, the value for a given TagName applies to all below levels, unless that TagName is set to a different value.
> 
> ### Section 3.3.1, paragraph 9
> 
> Does the use of a real album add to the understanding of the example? Please
> review the final paragraph of the [IESG Statement on Assignable Codepoints for
> Examples in IETF
> Specifications](https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/).
> 
> I changed this in https://github.com/ietf-wg-cellar/matroska-specification/pull/1045 
> 
> [MB] Looks good.
> 
> Applied for the next draft.
> 
> ### Section 3.3.1, paragraph 9
> 
> Consider moving these examples to an appendix.
> 
> I think having the examples next to the rules explanations is better for readability.
> 
> ### Section 4.10, paragraph 1
> 
> "usually" implies that they're not always. What do you do if they
> aren't?
> 
> Until recently, when we added the EBU loudness values, there was only one binary Tag, and it’s not in this section.
> If they aren’t they must be parsed according to the description. At least for the values that need to be used for playback like replaygain. 
> 
> ### DOWNREFs
> 
> Many possible DOWNREFs from this Standards Track doc to `[ID3v2.4]`,
> `[EBU-TECH.3342]`, `[ISRC]`, , `[EBU-TECH.3341]`, `[EBU-R.128]`, `[ReplayGain]`,
> `[IMDb]`, `[ISBN]`, `[GS1]`, `[MovieDB]`, `[ID3v2.3]`, `[ISO4217]`,
> `[IEEE.754]`, `[TheTVDB]`, `[LCCN]`.
> 
> These all look appropriate in context, but the IESG may need to approve these.
> 
> Given to interpret the values of these tags we need to have these specifications, I think they are normative.
> 
> ## Nits
> 
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Unless commented below I put your suggestions in this (big) Pull Request: https://github.com/ietf-wg-cellar/matroska-specification/pull/1061
> 
> 
> ### Typos
> 
> #### Section 3, paragraph 14
> ```
> -    In this way, it becomes possible to store any SimpleTag as attributes
> -                                                                        -
> +    In this way, it becomes possible to store any SimpleTag as an attribute
> +                                                                +++
> ```
> 
> #### Section 3.2.1, paragraph 4
> ```
> -    '_' for non official tags that are not meant to be added to the list
> -             ---
> +    '_' for unofficial tags that are not meant to be added to the list
> +            +
> ```
> 
> This has been turned into unassigned in https://github.com/ietf-wg-cellar/matroska-specification/pull/1048 
> 
> #### Section 3.2.2, paragraph 3
> ```
> -    but given there is no defined delimiters they cannot be easily split
> -                    ^^
> +    but given there are no defined delimiters, they cannot be easily split
> +                    ^^^                      +
> ```
> 
> #### Section 3.2.2, paragraph 4
> ```
> -    Due to the varied nature of tag sources it may also not always
> -                                                   -----
> +    Due to the varied nature of tag sources it may not always be
> +                                                             +++
> ```
> 
> This paragraph is a followup to the varied sources in the previous paragraph. So I think “also” works here.
> 
> #### Section 3.2.2.1, paragraph 2
> ```
> -    To store less accurate dates, parts of the date string are removed
> -                           ^ ^^
> +    To store less accurate timestamps, parts of the date string are removed
> +                           ^^^^^^ ^^
> ```
> 
> Given “date string” is used right after it’s odd to use timestamps here when it’s not used anywhere else.
> 
> #### Section 3.3, paragraph 3
> ```
> -    For human readability a TargetType string can be added next to the
> +    For human readability, a TargetType string can be added next to the
> +                         +
> ```
> 
> #### Section 3.3, paragraph 9
> ```
> -    Multiple SimpleTag with the same TagName can be used at a given
> +    Multiple SimpleTags with the same TagName can be used at a given
> +                      +
> ```
> 
> #### Section 3.3.1, paragraph 6
> ```
> -    For example if you have an album with 10 tracks and you want to tag
> -    the second track from it.  You set "TOTAL_PARTS" to "10" at
> -                     ^^^^     --------
> +    For example if an album has 10 tracks,
> +    the second track can indicate this.  "TOTAL_PARTS" is set to "10" at
> +                     ^^^  +++++ ++++++                 +++++++
> ```
> 
> I reworded your suggestion a little:
> “For example if an album has 10 tracks, tag the second track from it,
> you set "TOTAL_PARTS" to "10" at `TargetTypeValue` 50 (ALBUM)."
> 
> #### Section 3.3.1, paragraph 6
> ```
> -    that is specified in the file.  So, if it's TargetTypeValue = 30
> -                                    ------------
> ```
> 
> I prefer to keep this to make it less abstract.
> 
> #### Section 3.3.1, paragraph 6
> ```
> -    (TRACK), then that means the album contains 10 tracks.  If
> -           - ^^^^^^^^^     -                             ^^^^^
> -    TargetTypeValue is 20 (MOVEMENT), that means the album contains 10
> -                    ^^              - ^^^^     -
> -    movements, etc.  And since it's the second track within the album,
> -                     ^^^^^^^^^^^^^^
> +    (TRACK) would mean the album contains 10 tracks,
> +            ^^^^^                                  ^
> +    TargetTypeValue = 20 (MOVEMENT) would mean the album contains 10
> +                    ^               ^^^^^
> +    movements, etc.  For the second track within the album,
> +                     ^^^
> ```
> 
> ### Section 3.3.1, paragraph 7
> 
> Consider a bulleted list here. This list of tags is quite dense.
> 
> #### Section 3.3.1, paragraph 7
> ```
> -    If the parts are split into multiple logical entities, you can also
> -    use "PART_OFFSET".  For example you are tagging the third track of
> -    the second CD of a double CD album with a total of 10 tracks the
> -                             ^
> +    the second CD of a double-CD album with a total of 10 tracks the
> +                             ^
> ```
> 
> Form what I understand you’re suggesting to remove the part that talks about PART_OFFSET. This would be odd given that’s the point of that paragraph.
> 
> #### Section 3.3.1, paragraph 8
> ```
> -    When a TargetTypeValue level doesn't exist it MUST NOT be specified
> +    When a TargetTypeValue level doesn't exist, it MUST NOT be specified
> +                                              +
> ```
> 
> #### Section 3.4, paragraph 2
> ```
> -    words the tags apply to each entity defined by a UID.  This is the
> +    words, the tags apply to each entity defined by a UID.  This is the
> +         +
> ```
> 
> #### Section 4.1, paragraph 2
> ```
> -       |          |        | tags) to country specific information   |
> -                                    ^        ^                     --
> +       |          |        | tags) with country-specific information |
> +                                   ++ ^        ^
> ```
> 
> #### Section 4.9, paragraph 2
> ```
> -      |              |       | number is between 0 and 5 with stored |
> -                                                        ^^^^^
> +      |              |       | number is between 0 and 5, stored |
> +                                                        ^
> ```
> 
> #### Section 5, paragraph 6
> ```
> -    contain a URL.  Bogus or altered URLs may direct the user to unwanted
> -                    ^ -
> +    contain a URL.  Malicious or altered URLs may direct the user to unwanted
> +                    ^^^^^^
> ```
> 
> A URL may be bogus without it being a malicious intent.
> 
> #### Section 5, paragraph 7
> ```
> -    add some limits to the amount of nesting possible to avoid such
> -   ---------      ----
> ```
> 
> If I remove that whole block sentence becomes
> “A host app **MAY** issues"
> 
> That does not seem right.
> 
> ### URLs
> 
> These URLs in the document can probably be converted to HTTPS:
> 
> * http://wiki.hydrogenaud.io/index.php?title=Replay_Gain_specification
> 
> Fixed in https://github.com/ietf-wg-cellar/matroska-specification/pull/1060 
> 
> ### Grammar/style
> 
> #### Section 3.2.2.2, paragraph 1
> ```
> on-number character are found, they are be ignored, * if only one "." charact
>                                    ^^^^^^
> ```
> Consider using either the present participle "are being" or "are to be" here.
> 
> I used “are ignored”. It matches with the other sentences.
> 
> #### Section 3.3, paragraph 2
> 
> Consider reworking this to be more concise. For example,
> 
>   To relate information (e.g., "TITLE") to a certain scope (CD title or track
>   title), TargetTypeValue values and TargetType names can be used.  The same
>   tag name can have different meanings depending on its TargetTypeValue.
> 
> It is more concise but it’s less clear that for each level (that you call scope) we need a set of TargetTypeValue and TargetType. And that’s why the TargetTypeValue is impossible for each TargetType.
> 
> #### Section 3.3, paragraph 9
> ```
> etTypeValue 30 (TRACK) is "3", and the the "PART_OFFSET" at TargetTypeValue 3
>                                   ^^^^^^^
> ```
> Possible typo: you repeated a word.
> 
> #### Section 4.10, paragraph 2
> ```
> | | (track, album, etc). | +--------------------------------
>                    ^^^
> ```
> In American English, abbreviations like "etc." require a period.
> 
> #### Section 4.10, paragraph 2
> ```
> | | (track, album, etc). | +--------------------------------
>                    ^^^
> ```
> In American English, abbreviations like "etc." require a period.
> 
> #### Section 4.10, paragraph 2
> ```
> OC of | | | | the CDROM that this item was taken | |
>                  ^^^^^
> ```
> Consider using "CD-ROM".
> 
> #### Section 4.11, paragraph 1
> ```
> e diffusion of files containing these information. 6. IANA Considerations 6.1
>                                ^^^^^^^^^^^^^^^^^
> ```
> The plural determiner "these" does not agree with the singular noun
> "information".
> 
> Indeed, in English information cannot be counted whereas in French it can. I would use “informations” but it doesn’t seem correct: https://en.wiktionary.org/wiki/informations#English
> 
> I used "pieces of information", although I always find this concept very odd.
> 
> #### Section 5, paragraph 4 and 5
> ```
> -    String tags that are parsed like "REPLAYGAIN_GAIN" or
> -                                ^^^^
> -    "REPLAYGAIN_PEAK" defined in Section 4.10 or string tags following
> -                                             ^^^
> -    the rules from Section 3.2.2 or string tags following other strict
> -    formats like URLs may cause issues when the string is bogus or in an
> -                                                          ---------
> +    String tags that are parsed (such as "REPLAYGAIN_GAIN" or
> +                                ^^^^^^^^
> +    "REPLAYGAIN_PEAK", defined in Section 4.10), string tags following
> +                     ^                        ^^
> +    the rules from Section 3.2.2, or string tags following other strict
> +                                +
> ```
> 
> ```
> -    Binary tags that need to be parsed like "MCDI" defined in
> -                                       ^^^^
> -    Section 4.11 may cause issues when the data is bogus or incomplete.
> -                                                   ^^^^^
> +    Binary tags that need to be parsed (such as "MCDI", defined in
> +                                       ^^^^^^^^       +
> +    Section 4.11) may cause issues when the data is invalid or incomplete.
> +                +                                   ^^^^^^^
> ```
> 
> Using "like" here is ambiguous as to whether you're referring to tags which
> require parsing (and these are examples) or to the set of tags whose parsing
> method is similar to that of these tags.