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

[Mike Bishop <[e-mail]>]

Some comments inline with [MB].

________________________________
From: Steve Lhomme <[e-mail]>
Sent: Sunday, January 11, 2026 8:53 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)

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

### 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.
  *
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.

### 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.

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.

### 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.

### 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.

### 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.