Markdown Version | Session Recording

Session Date/Time: 27 Jan 2026 20:00

CELLAR

Summary

The CELLAR Working Group discussed the status of several drafts, including the TAG-20 (Matroska Tags) and CODEC drafts, focusing on AD evaluation comments and proposed resolutions. A significant portion of the meeting was dedicated to clarifying the concept of "Matroska V5" as a backwards-compatible feature set rather than a breaking protocol version. The group also revisited the fundamental motivation for hosting CELLAR's work within the IETF, particularly in light of potential rechartering discussions. Logistics for AD evaluation comments and potential in-person meetings were also addressed.

Key Discussion Points

• AD Evaluation Comments Distribution:

  • There was confusion regarding whether AD evaluation comments are sent to the working group mailing list. Robert noted that they typically go directly to draft authors and chairs.
  • It was decided that such comments should be forwarded to the mailing list for broader visibility within the working group.

• TAG-20 (Matroska Tags) Draft Status:

  • Steve provided an update on the TAG-20 draft, noting that most AD comments have been addressed, with one outstanding issue related to "latinized names" for IANA registry tags.
  • The proposed resolution for IANA registered tag names is to restrict characters to A-Z, 0-9, and underscore. This aligns with the historical spirit of the specification and provides clarity.
  • This change is captured in Pull Request #1065.
  • It was clarified that this rule applies to assigned (IANA registered) tags, while users are free to use other UTF-8 characters for unofficial tags, maintaining backward compatibility. The IETF perspective on assigned vs. unassigned code points was discussed.
  • Steve plans to push this change and publish a new draft version (likely -21) after a short comment period.

• CODEC Draft Status:

  • The CODEC draft moved quickly through AD evaluation.
  • A key comment from the AD evaluation concerned normative references to IEEE and ISO standards that are not freely available.
  • The working group acknowledged the general IETF policy regarding such references and the arrangements for reviewers/ADs to access them for evaluation purposes (e.g., with IEEE, and possibly parts of ISO).
  • The discussion revolved around whether the IETF document specifies the "box" (container) or the "bits in the box" (codec itself), which influences the criticality of free access to referenced standards.
  • The group agreed to defer deeper discussion on this draft to allow members to review the AD comments.
  • It was noted that "Chapter Codecs" will be revisited in 2026.

• FFV1 Draft Status:

  • The FFV1 draft is awaiting further secretization with implementations.
  • Mori (the AD) confirmed that dateless milestones are acceptable for this draft.
  • Recommendations for Mori regarding past reports have been provided.

• Matroska V5 Discussion:

  • The working group sought to clarify the meaning of "Matroska V5" as it applies to the draft.
  • It was emphasized that "V5" does not imply a breaking change in the Matroska format itself, meaning V5 files would be backward-compatible with V4 implementations (which would simply ignore unknown elements).
  • Instead, "V5" represents a new set of backwards-compatible elements or features that build upon the existing Matroska V4 specification (e.g., adding colorimetry or an "emphasis" element relevant for archival of audio from CDs/vinyl).
  • The "version" number serves more as a marketing or capability signal, allowing implementers to refer to a specific set of supported features.
  • The IETF's common understanding of "versioning" (e.g., HTTP 1.1 vs 2 vs 3) as potentially breaking changes was contrasted with Matroska's approach.
  • A truly breaking change (e.g., using rational numbers for timestamps instead of floats/nanoseconds) would warrant a clearer signal of incompatibility, but this is not currently planned.
  • Robert will explore how other IETF protocols have handled similar issues with container/XML element extensions and versioning.

• Motivation for IETF Hosting and Rechartering:

  • The working group discussed the unique value proposition of the IETF for CELLAR's work, particularly in the context of potential rechartering.
  • Key arguments for IETF hosting include:
    • Openness: The IETF's open standardization process is a significant benefit, attracting diverse expertise that might not be found in more closed organizations (e.g., specific XML, UTF-8, float value, or protocol versioning experts).
    • Standards Expertise: The IETF's rigorous review process and expertise in developing robust internet standards are valuable.
    • Community Engagement: The open nature allows institutions (e.g., those invested in WebM) to contribute effectively.
  • Dave recalled earlier discussions from around 2015/2016, where arguments included the declining relevance of lossless media on the internet (which is now seen as less valid) and the comparison to other bodies like SMPTE.
  • Martin raised the question of including FLAC in potential rechartering efforts, noting its 20-year history and potential for extensions. Opinions on this are sought on the mailing list.

• Potential In-Person Meeting:

  • The idea of holding a working group meeting at an IETF plenary was discussed to attract new expertise through broader exposure.
  • The Vienna IETF meeting (July 18-24) was suggested as a potentially convenient location for European participants.
  • Challenges include travel costs and IETF meeting registration fees.

• AudioVivid 3D Audio Codec:

  • A request regarding the AudioVivid 3D audio codec for Matroska was noted. Steve will draft a reply to the mailing list, suggesting it could be added to a future document (e.g., the Matroska V5 document) as a new element.

Decisions and Action Items

• Decision: AD evaluation comments (received directly by authors/chairs) for all CELLAR drafts will be forwarded to the working group mailing list.
• Action Item: Steve to push the resolution for TAG-20 (Matroska Tags) IANA registry names (A-Z, 0-9, underscore) via PR #1065 and publish the next draft version (-21) after a short comment period.
• Action Item: Spencer to confirm the availability of IEEE and ISO/ITU standards for IETF evaluation purposes with Stefan Wenger (liaison) and the RFC Editor, to address comments on the CODEC draft.
• Action Item: Spencer to socialize the idea of holding a CELLAR working group meeting at the IETF Vienna plenary (July 18-24) with the ISG scheduling side.
• Action Item: Steve to draft a proposed reply to the mailing list regarding the AudioVivid 3D audio codec for Matroska.
• Action Item: Robert to seek input from IETF experts who have defined XML containers and managed versioning/feature sets in other protocols to inform the Matroska V5 discussion.
• Action Item: Martin and other interested parties to send messages to the mailing list with opinions on whether to include FLAC in potential CELLAR rechartering.

Next Steps

• Working group members to review the AD evaluation comments for the CODEC draft once forwarded to the mailing list.
• Monitor progress of TAG-20 draft publication and respond to any new AD comments.
• Continue discussions on the meaning and signaling of "Matroska V5" as a feature set.
• Engage on the mailing list regarding the inclusion of FLAC in any rechartering discussions.
• Further exploration of an in-person meeting in Vienna.