Matroska Media Container Tag Specifications
draft-ietf-cellar-tags-24

[Ballot comment]
Thank you for your changes to address my previous DISCUSS. I have one outstanding comment that I hope you will consider, but it's not blocking.

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 earlier suggestion that a completely non-conformant tag might still be considered valid but unregisterable. But your response 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. Is this section intended to preclude registration of non-conformant tags or intended to preclude their presence in a conformant segment?

[Ballot comment]
Hi Steve, Moritz, and Dave,

Thank you for the discussion and for taking care of the comments. Much appreciated.

The changes made in [1] address most of the points raised in my previous ballot [2].

# Pending issue

I still see, however, that we are mixing normative behavior with IANA considerations (Section 6.1), but I will leave that to the responsible AD to work it out with the authors.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cellar-tags-20&url2=draft-ietf-cellar-tags-22&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/cellar/kca-aLZ-XWZpR7X5ZIxFPKm4Qac/

[Ballot comment]
Thanks for the work done in this document, and the follow-up on my previous DISCUSS.

I am trusting the authors and the responsible AD that the PR 1083 will be merged and a revised I-D submitted (see https://mailarchive.ietf.org/arch/msg/cellar/HZEUYMiPtwhD198vBsfZEBWPUWw/ ).

Regards

-éric

[Ballot comment]
Thank you to Ines Robles for the GENART review.

I support the DISCUSS position of Mohamed Boucadair, Gorry Fairhurst, and Éric Vyncke.

Thank you for addressing my DISCUSS and COMMENT feedback.

[Ballot comment]
Thank you for the new revision that addresses my DISCUSS topics, and the comments below.

--

I have several comments that I hope may improve this:

1. Please could you make this abstract more descriptive? It's hard to understand what the document might contain from the abstract. There are many sentences in the introduction that would help. For example these text fragments could be helpful;:

Matroska is a multimedia container format that can store timestamped multimedia data but also chapters and tags. ... This document defines  ... a set of common tag names used in Matroska. These Tag elements add metadata to identify and classify the information found in a Matroska Segment. ...

2. The document contains the names of several example physical entities in the entertainment industry. I am not yet persuaded that this necessary or even helpful to have actual rather than exemplar identities named.

3. There is a section on Official Tags, which says: "The following is a complete list of the supported Matroska Tags." -- Is that the present value? The only permitted value until this RFC-to-be is updated? This is often phrased as /complete/assigned/ or some similar change (see DISCUSS point).

[Ballot 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
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.

### What is "official"?

I share others' issues with the term "Official". Enough has been said at enough
length, I think.

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

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot 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".

Second, RFCs should generally avoid the first-person. Maybe "This document's"?
Consider removing the first/second-person usage throughout the document.

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.

### Section 3.2.2, paragraph 1
```
    should be used so everyone can agree on how to use the value.
```
...so as to improve interoperability.

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

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

### Section 3.3, paragraph 8

Or below? Presumably stopping a value at one level also cascades.

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

### Section 3.3.1, paragraph 9

Consider moving these examples to an appendix.

### Section 4.10, paragraph 1

"usually" implies that they're not always. What do you do if they
aren't?

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

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

### 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
+            +
```

#### 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
+                                                            +++
```

#### 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
+                          ^^^^^^ ^^
```

#### 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
+                    ^^^  +++++ ++++++                +++++++
```

#### Section 3.3.1, paragraph 6
```
-    that is specified in the file.  So, if it's TargetTypeValue = 30
-                                    ------------
```

#### 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
+                            ^
```

#### 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
+                    ^^^^^^
```

#### Section 5, paragraph 7
```
-    add some limits to the amount of nesting possible to avoid such
-  ---------      ----
```

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://wiki.hydrogenaud.io/index.php?title=Replay_Gain_specification

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

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

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

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

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-cellar-tags-20
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cellar-tags-20.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Thanks to the Reviewers

I want to thank the many reviewers of this draft, particularly Sean Turner for his
ARTART review.

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

### UTF-8 and Problematic Code Points.

196        Official TagName values MUST consist of UTF-8 capital letters,
197        numbers and the underscore character '_'.

In addition to Roman's DISCUSS on capitalized UTF-8, should the tags be
limited to exclude the problematic code points as described in RFC 9839?

And from your Security Considerations sections:

1671      Most of the time strings are kept as-is and don't pose a security
1672      issue, apart from invalid UTF-8 values.  Implementations MUST
1673      validate TagString inputs for UTF-8 correctness and reasonable length
1674      before use, in accordance with the security considerations in
1675      Section 10 of [RFC3629].

I think you have to apply RFC 9839 to make a statement that UTF-8 values
don't apply a security risk.

### Beginning Underscore

204        It is RECOMMENDED that tag names start with the underscore character
205        '_' for non official tags that are not meant to be added to the list
206        of official tags.

Why is the RECOMMENDED? Can it be a MUST? If it is RECOMMENDED, what are the ramifications of not following the recommendation?

### TagString Formatting

215        Multiple items SHOULD NOT be stored as a list in a single TagString.
216        If there is more than one tag value with the same name to be stored,
217        it is RECOMMENDED to use separate SimpleTags with that name for each
218        value.

Can this be a MUST NOT? Why allow them to be stored as a list at all. And if this advice is not followed,
what happens? Is it that some software won't interoperate? If that is the case, I think you are better off
stating this as a MUST NOT.

220        Preexisting files may have used multiple values in the same TagString
221        but given there is no defined delimiters they cannot be easily split
222        into multiple elements.  INSTRUMENTS (Section 4.4) and KEYWORDS
223        (Section 4.6) tags allow using a comma as a separator.  However, it
224        is RECOMMENDED to use separate SimpleTags with each containing a
225        single instrument or keyword value, respectively.

Why are separate tags only RECOMMENDED? Can this be a MUST as well? If it is to remain as a RECOMMENDED,
what are the consequences of not following the recommendation?

[Ballot comment]
## Comments

### Support Of Other DISCUSS Positions

I support Éric's DISCUSS on UTF-8 spaces. Should that be whitespace?

I support Gory's position on the "Official". IMHO, the doc is describing "registered" values, not "official" values.

And like Gory, I support Med's position on the specification required for DEs.

[Ballot comment]
I agree with most DISCUSS points raised by the other ADs. Additionally, I'd like to point out:

- It seems the FSFC policy being used while the document talks about "official tags", seems to imply that FCFS is not the best choice. Perhaps Expert Review is the better choice?
- The use of "we" should be avoided, as it is unclear which group that refers to (authors, WG, IETF, etc)

[Ballot 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”?

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

** 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?

[Ballot 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?

-- I found the terms “free” and “strict” confusing.  Is this “free-form” as opposed to being without cost?  “Strict” relative to what?

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

** 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”?

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

** Section 3.2.1
  Official TagName values MUST NOT contain any space.

Is this the same as saying must not contain “space characters”?

** 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?

** 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?

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

[Ballot comment]
Thanks to Mohit Sethi for their secdir review.

General:  I agree with Med's discuss on neutral examples. It would be better if these examples pointed to obvious fictitious entities. 

Abstract:  I agree with Gorry that this needs to be a little more descriptive.

Section 3.1, etc.:  Please define 'official', or change the word to something more obvious - 'defined' or 'common'. 

Nits:
Section 3.1, last sentence:  s/wanted/desired
Section 3.2.1, last sentence:  s/non official/unofficial

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-cellar-tags-20
CC @evyncke

Thank you for the work put into this document even if I find a little weird to have tag definitions of a container done in a codec WG, but it fits the CELLAR WG charter, so all is good.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Spencer Dawkins for the shepherd's detailed write-up including the WG consensus (albeit a small WG it seems) and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Missing version

The CELLAR charter includes `Standards Track specification for Matroska container format version 4` but this I-D, while proposed standard, does not mention at all the version 4. So, it is really unclear.

Note: RFC 9559 section 7 is about versioning, but this I-D should really mention version 4.

### Section 3.2.1

Happy to be corrected as I am not a UTF-8 expert, but what is the exact definition of `any space`? again thinking about UTF-8 and https://en.wikipedia.org/wiki/Whitespace_character

### Section 4.11

`Library of Congress Control Number` but from which country? This definition is ambiguous.

[Ballot comment]

## COMMENTS (non-blocking)

### Support for others DISCUSS points

I second (hence won't repeat) the following DISCUSS points by Med:
- use of BCP14 in IANA considerations
- other issues mentioned in the IANA considerations

I note though that IANA tagged (punt intended) this I-D as "IANA OK"

### Abstract

Abstracts need to be concise but also useful and descriptive. I.e., at least mention the version (per my DISCUSS point) and be more descriptive.

The title should also include "version 4".

### Section 1

Please expand `EBML` at first use.

### Use of personal pronouns

Let's avoid the use of personal pronouns such as `if you wanted to store` (section 3) or `We also need an official list` (section 3.1) or even `Our recommendations are in between` and `put any tag in your file` (section 3.1 albeit not pronouns ;-) ). I.e., who is the "we" ? The authors ? The WG ? The IETF ?

### Use of 'official'

As noted in other ballots, please refrain using `official`, the IETF issues standards and not laws; so, s/official/standard/ would be much better.

### Section 3.2.1

`UTF-8 capital letters`, I am not a UTF-8 or internationalisation expert, but do all alphabets have "capital letters" (and should it be "character" rather than `letter`)

### Section 3.2.2

Why not a MUST in `Multiple items SHOULD NOT`? See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 3.2.2.2

A long discussion about the decimal '.' vs. ',', but nothing is written in which base the "UTF-8 number" is represented. I guess base 10, but let's be specific. I also wonder why not using a IEEE binary format was not used (possibly for backward compatibility).

### Section 3.3.1

Should there be a definition or reference for `TagChapterUID`? (also for other *UID terms).

[Ballot discuss]
I have two document concerns: Relating to current text that says: "Matroska Tag Names for binary data are to be allocated according to the "Specification Required" policy [RFC8126]."

* I support the DISCUSS by Med, relating to the need for additional text in the IANA Section on the Specification required policy, and guidance for Designated Experts (DE).

* I'd like to DISCUSS the use the word "Official" in this I-D, because I find this is an unusual word to use in an IETF Specification to describe an entry in an IANA Registry. I'd expect to see a word such as "assigned" or "allocated".

[Ballot comment]
I have several comments that I hope may improve this:

1. Please could you make this abstract more descriptive? It's hard to understand what the document might contain from the abstract. There are many sentences in the introduction that would help. For example these text fragments could be helpful;:

Matroska is a multimedia container format that can store timestamped multimedia data but also chapters and tags. ... This document defines  ... a set of common tag names used in Matroska. These Tag elements add metadata to identify and classify the information found in a Matroska Segment. ...

2. The document contains the names of several example physical entities in the entertainment industry. I am not yet persuaded that this necessary or even helpful to have actual rather than exemplar identities named.

3. There is a section on Official Tags, which says: "The following is a complete list of the supported Matroska Tags." -- Is that the present value? The only permitted value until this RFC-to-be is updated? This is often phrased as /complete/assigned/ or some similar change (see DISCUSS point).

[Ballot discuss]
Hi Steve, Moritz, and Dave,

Thank you for the effort put into this document.

I have few process-related DISCUSS points:

# Neutral examples

The document includes several examples, that I suspect echo authors favorites. However, per the IESG statement on “IESG Statement on Assignable Codepoints for Examples in IETF Specifications” [1], “patterns such as including product information, political matters, or names of identifiable individuals should be avoided.”

Please consider updating the examples to use more neutral ones.

# Normative language in an IANA Section

Per the IESG statement on “IESG Statement on Clarifying the Use of BCP 14 Key Words”, use of normative language in inappropriate in the IANA Considerations section. Please update accordingly.

CURRENT:
  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,

# How to ensure that distinct attributes are not covering the same piece of information, especially for the FCFS ones?

CURRENT:
  Matroska Tag Names for UTF-8 data are to be allocated according to
  the "First Come First Served" policy [RFC8126].

Maybe I misinterpreted the intended use of “Reference”, but it would be more convenient for the IANA registry to include a description of the attribute. 

# Are there provisions for tagging specific attributes as deprecated in the future? Should that be reflected in the registry (e.g., Status)?

# Specification required policy

As a reminder, RFC8126 says:

  For the Specification Required policy, review and approval by a
  designated expert (see Section 5) is required, and the values and
  their meanings must be documented in a permanent and readily
  available public specification, in sufficient detail so that
  interoperability between independent implementations is possible.
  This policy is the same as Expert Review, with the additional
  requirement of a formal public specification.

## DE Guidelines should be provided as well.

## Do you expect allowing registrations based on individual I-Ds, for example?

[Ballot comment]
# Official tags

I would introduce what is meant by “official” tag early in the document. At least, I didn’t find such concept in two RFCs cited in the terminology section.

Cheers,
Med

[1] https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/

[2] https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cellar-tags-19. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the Matroska Tags Names registry.

IANA QUESTION -> Where should this new registry be located? Is it a new registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

Each registration in the new registry consists of a Name, Type, Change Controller and Reference.

The registration policy for the new registry is based on the type and is as follows:

The Type corresponds to which element will be stored the tag value. There can be 3 values for the Type:

UTF-8: the value of the Tag is stored in TagString,
Matroska Tag Names for UTF-8 data are to be allocated according to the "First Come First Served" policy as defined in [RFC8126].

binary: the value of the Tag is stored in TagBinary,
Matroska Tag Names for binary data are to be allocated according to the "Specification Required" policy as defined in [RFC8126].

nested: the tag doesn't contain a value, only nested tags inside.
Matroska Tag Names for nested tags are to be allocated according to the "Specification Required" policy as defined in [RFC8126].

There are initial registrations in the new registry. They are found in Table 17 in Section 6.1 of the current draft.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-10-13):

From: The IESG
To: IETF-Announce
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-tags@ietf.org, orie@or13.io, spencerdawkins.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Matroska Media Container Tag Specifications) to Proposed Standard


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'Matroska Media Container Tag Specifications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-10-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the Matroska multimedia container tags, namely
  the tag names and their respective semantic meaning.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-tags-18

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The WG is small (6-8 active participants), and the authors are the most active contributors, but the entire active working group was involved in reaching consensus for this document.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No. This working group is quite calm, and work on draft-ietf-cellar-tags was no exception.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

4. For protocol documents, are there existing implementations of the contents of
the document?

Yes. Notable implementations include vlc, ffmpeg, mkvtoolnix, mediainfo.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Pretty much all the relevant people participate in this IETF WG.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not contain any MIB, YANG module, new media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

This document does not contain any YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes. The document shepherd did a full top-to-bottom review of draft-ietf-cellar-tags-15 which resulted in some significant technical changes, but these changes involved

- tightening BCP 14 language

- providing context for SHOULDs that provide direction for new media containers while not invalidating existing containers - Matroska is intended for use in archival media storage, so allowing conformant implementations to process these containers is critical

- providing explanations for concepts that the working group understands very well, but new implementers might not understand

10.Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues with common issues have been identified for this document - the document content is application-level, and provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, so no additional issues with common issues are expected here.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard is appropriate for this document. It provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, which is also published as Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes. Document authors have been surveyed. All have confirmed in email that no disclosures have been made, and no disclosures are expected..

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes. Document authors have agreed. There are three authors.

14.Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Beyond the Content Guidelines, idnits 2.17.1 identifies possible downrefs, but please see below. :

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

The Normative references really are normative. The Informative references are really informative.

We use a format SIMILAR TO the profile for [ISO8601] International Organization for Standardization, "Date and time — Representations for information interchange — Part 1: Basic rules", ISO 8601-1:2019, February 2019,  as defined in [RFC3339],  but the format is defined in the current draft.

16.List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

  ref. 'GS1' is freely available.

  ref. 'IEEE.754' is available for purchase.

  ref. 'IMDb' is freely available.

  ref. 'ISBN' is freely available 

  ref. 'ISO4217' is freely available

  ref. 'ISRC' is freely available

  ref. 'LCCN' is freely available.

  ref. 'MovieDB' is freely available.

  ref. 'ReplayGain' is freely available.

  ref. 'TheTVDB' is freely available.

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'GS1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IMDb'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISBN'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISRC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'LCCN'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'MovieDB'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ReplayGain'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TheTVDB'

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs?

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

This document creates a new registry called the "Matroska Tag Names" registry.

The new registry uses the "Specification Required" policy [RFC8126].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-tags-18

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The WG is small (6-8 active participants), and the authors are the most active contributors, but the entire active working group was involved in reaching consensus for this document.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No. This working group is quite calm, and work on draft-ietf-cellar-tags was no exception.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

4. For protocol documents, are there existing implementations of the contents of
the document?

Yes. Notable implementations include vlc, ffmpeg, mkvtoolnix, mediainfo.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Pretty much all the relevant people participate in this IETF WG.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not contain any MIB, YANG module, new media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

This document does not contain any YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes. The document shepherd did a full top-to-bottom review of draft-ietf-cellar-tags-15 which resulted in some significant technical changes, but these changes involved

- tightening BCP 14 language

- providing context for SHOULDs that provide direction for new media containers while not invalidating existing containers - Matroska is intended for use in archival media storage, so allowing conformant implementations to process these containers is critical

- providing explanations for concepts that the working group understands very well, but new implementers might not understand

10.Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues with common issues have been identified for this document - the document content is application-level, and provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, so no additional issues with common issues are expected here.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard is appropriate for this document. It provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, which is also published as Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes. Document authors have been surveyed. All have confirmed in email that no disclosures have been made, and no disclosures are expected..

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes. Document authors have agreed. There are three authors.

14.Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Beyond the Content Guidelines, idnits 2.17.1 identifies possible downrefs, but please see below. :

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

The Normative references really are normative. The Informative references are really informative.

We use a format SIMILAR TO the profile for [ISO8601] International Organization for Standardization, "Date and time — Representations for information interchange — Part 1: Basic rules", ISO 8601-1:2019, February 2019,  as defined in [RFC3339],  but the format is defined in the current draft.

16.List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

  ref. 'GS1' is freely available.

  ref. 'IEEE.754' is available for purchase.

  ref. 'IMDb' is freely available.

  ref. 'ISBN' is freely available 

  ref. 'ISO4217' is freely available

  ref. 'ISRC' is freely available

  ref. 'LCCN' is freely available.

  ref. 'MovieDB' is freely available.

  ref. 'ReplayGain' is freely available.

  ref. 'TheTVDB' is freely available.

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'GS1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IMDb'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISBN'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISRC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'LCCN'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'MovieDB'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ReplayGain'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TheTVDB'

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs?

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

This document creates a new registry called the "Matroska Tag Names" registry.

The new registry uses the "Specification Required" policy [RFC8126].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/