**Session Date/Time:** 24 Jan 2023 20:00

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

## Summary

The CELLAR Working Group met to discuss the status of its active drafts, focusing on Matroska and FLAC, and briefly touching upon FFV1. Key discussions revolved around technical issues identified during an Area Director (AD) review of the Matroska draft, including the interpretation of UUIDs and the reuse of deprecated element IDs. Updates on the FLAC draft's encoding specification approach were also covered. The group acknowledged ongoing work and set actions for document editors and participants.

## Key Discussion Points

*   **Previous Meeting Minutes:** There was initial confusion regarding the December meeting minutes. The correct minutes for the December 6th meeting were confirmed as having been sent to the mailing list, and participants were encouraged to review them.
*   **Document Status Updates:**
    *   `kodak-parmie`: No specific updates.
    *   `kodak-ffe1`: No specific updates.
    *   `flac`: Shepherd's write-up is still pending.
*   **Matroska (draft-ietf-cellar-matroska):**
    *   **UUID Definition:** An AD review highlighted that Matroska's current "UUIDs" do not align with IETF UUID semantics, which include specific meaning in their values.
        *   **Discussion:** It was noted that Matroska intended these as purely random identifiers. The spec for UUIDv4, which is largely random, was discussed as a potential recommendation for generation.
        *   **Decision:** The group agreed to modify the Matroska draft to recommend the use of UUIDv4 for generating these identifiers, but explicitly state that readers *must* treat them as opaque 128-bit strings, effectively clarifying they are not to be interpreted according to standard UUID semantics beyond their random generation.
    *   **Deprecated Element IDs:** A proposal was made to allow the reuse of deprecated element IDs to conserve the limited one-byte ID space.
        *   **Discussion:** Concerns were raised about potential backward compatibility issues if these IDs were used in the wild, even if unofficially. It was noted that two-, three-, and four-byte IDs have ample room and do not require reuse.
        *   **Decision:** For one-byte deprecated IDs, the group agreed to mark them as "returned" in IANA, indicating they can be reused *only* after all other one-byte codes are exhausted. This approach provides a safeguard and allows for community consultation if reuse becomes necessary. Two-, three-, and four-byte deprecated IDs will simply remain deprecated and not be reused.
*   **FLAC (draft-ietf-cellar-flac):**
    *   **Encoding Specification:** A question was raised from the mailing list about the need to specify encoding strategies, similar to other codecs like Opus and MP3.
        *   **Discussion:** The general consensus was that IETF specifications primarily focus on defining the format for decoding, allowing encoders flexibility and innovation within those rules. Mandating specific encoding methods can unnecessarily restrict future developments. Non-normative examples or references might be useful, but normative requirements for encoding are generally not desired.
        *   **Consensus:** The working group agreed that there is no need to add normative sections on encoding strategies or possibilities in the FLAC document.
*   **FFV1 (draft-ietf-cellar-ffv1):**
    *   No new technical updates for the existing version of the draft.
    *   **FFV1 in MXF:** A patch for FFmpeg supporting FFV1 in the MXF (Material Exchange Format) container is awaiting merge. MXF is used in broadcasting and archival contexts. The FFV1 document might benefit from a cross-reference to any SMPTE specification describing FFV1 within MXF.
    *   **FFV1 Version 4 Wishlist:** Participants were reminded of the existing "wish list" of potential features for a future FFV1 version 4 on the issue tracker.

## Decisions and Action Items

*   **Decision:** Matroska draft to recommend UUIDv4 generation for identifiers but mandate readers treat them as opaque 128-bit strings.
    *   **Action Item:** Matroska editor to implement this change.
*   **Decision:** For Matroska, one-byte deprecated IDs will be marked as "returned" in IANA for future reuse only after all other one-byte codes are exhausted. Multi-byte deprecated IDs will not be reused.
    *   **Action Item:** Matroska editor to update the draft accordingly and coordinate with IANA.
*   **Decision:** No normative section on encoding strategies will be added to the FLAC draft.
*   **Action Item:** All CELLAR participants to review the "wish list" for FFV1 version 4 on the FFV1 issue tracker, to be prepared for discussion at a future meeting.

## Next Steps

*   Matroska draft to be updated with decisions on UUIDs and deprecated IDs, then resubmitted for further AD review.
*   FLAC draft editor to complete the Shepherd's write-up. The draft is anticipated to finish the IETF process by approximately June.
*   The FFV1 draft remains stable. Discussion on FFV1 version 4 to be added to a future meeting agenda after participants review the wishlist.
*   The working group will continue to address any issues raised during ongoing reviews of the drafts.
*   Several participants will be attending FOSDEM, with an FFV1 presentation scheduled.