Session Date/Time: 28 Jun 2022 19:00

CELLAR

Summary

The CELLAR Working Group meeting focused primarily on the status of the Matroska specification document review and provided an update on the FLAC document. Key discussions revolved around technical clarifications for the Matroska draft, including BCP 14 language usage, handling of encryption, and the need for IANA media type registration. The Chairs reiterated the expectation for FLAC completion by the end of summer.

Key Discussion Points

FLAC Document Status:
- Martin stated his expectation for completing the FLAC document by the "end of summer."
- He is currently working on specifics and aims to have working code before integrating details into the specification.
- Michael suggested dedicating the August call to FLAC issues if needed, which Martin agreed could act as a forcing function for review.
IETF 120 (Prague):
- The dates for IETF 120 in Prague are October 26-28.
- The venue for the Friday session will be in The Hague.
- Michael plans to attend the Friday session in The Hague.
Matroska Specification Document Shepherd Review:
- Michael conducted a top-to-bottom read of the document, focusing on identifying issues for ISG and other reviewers rather than technical objections.
- Steve reported that he had addressed most of Michael's comments and replies via pull requests (PRs).
- BCP 14 Language (MUST/SHOULD):
  - Discussion on the strictness of "MUST" versus "SHOULD" and "RECOMMENDED." Michael emphasized that unless exceptions are documented, "MUST" is generally preferred.
  - MetaSeek Element: For MetaSeek, it cannot be a "MUST" due to live streams where it's not usable. The proposed language is that encoders compliant to the specification "MUST" use MetaSeek unless the stream is live, and parsers "MUST" be tolerant of a missing MetaSeek (due to live streams or legacy files).
  - The concept of a "general recommendation" section in the document for best practices (e.g., why to include MetaSeek) was discussed, potentially allowing normative references from specific sections.
- Cluster Elements:
  - Clarified that a cluster with zero block groups and zero simple block elements, while useless, is not necessarily invalid.
  - PR 609 addresses this, stating a cluster "may not contain any block element for example in a live recording when no data has been collected."
- Timestamp Element:
  - The timestamp element "should be the first element in the cluster" or "second if that cluster contains a checksum element." This consistency was addressed in PR 608.
- Codec Information: Confirmed there's no need for other components beyond audio/video streams currently.
- Element Formatting: Steve reported making improvements to element formatting, saving 20 pages, despite limitations with Markdown-to-XML translation that prevent more advanced table layouts.
- Usage Notes vs. Rationale:
  - "Rationale" is for explaining why an element exists, keeping definitions concise.
  - "Usage Notes" are more normative, detailing implementation requirements (e.g., if you have X, you must have Y).
- UUIDs: Changed to use standard string representation for binary UUID values, improving clarity.
- Block Label: A change was made regarding the block label.
- Language Tags: Changed reference from "IETF element" to "BCP 47," which is the correct standard.
- Boolean Values (Copy/Don't Copy): A paragraph was added to explain the meaning of these boolean values.
- Content Encryption (ContentEncAlg):
  - Confirmed that encryption elements are used in WebM (e.g., YouTube) which uses Matroska parts.
  - To avoid detailed security review for current encryption mechanisms, it was agreed to state that "a detailed description of how to do this for modern algorithms is the subject of future work."
  - The document will link to the WebM page for current implementation details.
- IANA Registries for Enumerations:
  - Discussed whether various integer fields (enums) in Matroska require IANA registries for future extensibility.
  - The consensus was that most would not need an IANA registry. Changes to these values typically require a specification update (IETF action) due to their complex interpretation, rather than a first-come, first-served allocation.
  - It was clarified that the "IANA Considerations" section covers both requesting new registries and registering values in existing ones.
- MIME Types and File Extensions:
  - Discussion on the need for formal IANA media type registration, which includes file extensions. Michael will provide a template.
- HEX Values Reordering: The reordering of HEX values was implemented for better readability.

Decisions and Action Items

Decision: The FLAC document milestone will remain "end of summer," with flexibility for dedicated discussion during the August call if needed.
Action Item: Steve to merge all outstanding changes and post version 11 of the Matroska specification document.
Action Item: Michael to send Steve the IANA media type registration template for correctly registering the Matroska MIME type and file extensions (e.g., .mkv).
Action Item: Jerome to review FLAC specification pull requests #138 and #158.

Next Steps

The next CELLAR WG meeting is scheduled for August 23rd.
Steve to continue working on the Matroska specification draft based on the review feedback and post a new version.
Jerome to review the mentioned FLAC pull requests.