**Session Date/Time:** 22 Aug 2023 19:00

# [CELLAR](../wg/cellar.html)

## Summary

The CELLAR Working Group discussed outstanding issues for both the Matroska (RFC 8794) and FLAC documents. For Matroska, the focus was on clarifying the informative nature of `matroska-tags` to resolve a ballot "discuss" and following up on unverified errata. For FLAC, decisions were made regarding the handling of normative references to IETF procedural documents in boilerplate sections. The group also confirmed plans for a side meeting during IETF 118.

## Key Discussion Points

*   **Matroska (RFC 8794) - John's "Discuss" and Errata**
    *   **Errata Status**: Several errata for RFC 8794 reported by the working group remain unverified by the responsible AD. A sense of those present indicates the working group intends to follow up with the IESG/AD to request these be marked as verified.
    *   **Normativity of `matroska-tags`**: A "discuss" comment from John questioned whether the `matroska-tags` specification should be normative.
        *   The working group clarified that `matroska-tags` is intended to be informative. It is possible to implement a "useful version" of Matroska without supporting `matroska-tags`.
        *   Analogy was drawn to XML: the Matroska specification defines the core format (like XML syntax), while `matroska-tags` is an application using that format (like an XML schema for a specific purpose). The core Matroska specification is normative for `matroska-tags`, but not vice-versa.
        *   Examples like chapters for segmenting media (distinct from tags) and tags for arbitrary metadata (e.g., "beats per minute," "cover" vs. "original" songs) were used to illustrate their informative role. Most media players using Matroska do not support `matroska-tags`.
        *   `matroska-tags` are strings and do not require an IANA process for new entries.

*   **FLAC Draft - Reference Handling**
    *   **Media Type Registration Reference (RFC 6838)**: Discussion centered on whether the reference to RFC 6838 in the Media Type Registration section should be normative. A sense of those present indicates that this reference pertains to the *publication procedure* and not to *protocol implementation*.
        *   Decision was made to rephrase the text in Section 3 to state "This document registers one new media type" and remove the explicit reference to "in accordance with the procedure set forth in RFC 6838."
    *   **Implementation Status Reference (RFC 7942)**: An issue was raised regarding the normative reference to RFC 7942 for the "Implementation Status" section.
        *   The common practice is for the RFC Editor to remove the "Implementation Status" section before publication.
        *   A sense of those present indicates the section should remain in the draft for review purposes but include a note to the RFC Editor to remove the entire section and its corresponding reference (RFC 7942) prior to publication.
    *   **Ogg Mapping Reference**: Briefly noted that the Ogg mapping specification is an informative RFC, and its use is optional for FLAC implementers.
    *   **Previous Shepherd Review**: All points from the previous shepherd review (including those related to appendixes) were addressed in version 8 of the FLAC document. The current draft is version 10.

## Decisions and Action Items

**Decisions:**

*   **Matroska Errata**: The working group will follow up with the IESG/AD to request that the reported errata for RFC 8794 be marked as verified.
*   **Matroska Tags Normativity**: The working group will clarify in a reply to John that `matroska-tags` is intended to be an informative specification, not a normative requirement for core Matroska implementations.
*   **FLAC Media Type Registration**: The explicit reference to RFC 6838 in the "Media Type Registration" section will be removed; the text will simply state "This document registers one new media type."
*   **FLAC Implementation Status**: The "Implementation Status" section will remain in the FLAC draft during the review process, but a note will be added for the RFC Editor to remove the entire section and its reference to RFC 7942 before publication.
*   **Next Meeting Venue**: The next CELLAR meeting at IETF 118 will be held as a side meeting co-located with "No Time To Wait," rather than requesting an official IETF agenda slot.

**Action Items:**

*   **[Chair/Editor]**: Send an email to John clarifying the informative nature of `matroska-tags` in RFC 8794.
*   **Martin (Editor)**: Publish version 11 of the FLAC document incorporating the agreed changes (removal of explicit RFC 6838 reference, and a note for RFC 7942 removal).
*   **[Chair]**: Review FLAC draft version 11 once published, before it is submitted for last call.
*   **[Chair/WG Members]**: Announce the CELLAR side meeting at "No Time To Wait" via the IETF side meetings wiki page and explore the possibility of a brief presentation at "Hot RFC" on Sunday night of IETF 118.

## Next Steps

*   Publication of FLAC draft version 11.
*   Follow-up with IESG/AD regarding unverified RFC 8794 errata.
*   Communication to John about the `matroska-tags` clarification.
*   Planning and announcement of the CELLAR side meeting at IETF 118.