[Cellar] purpose of FLAC RFC --- vs xiph.org

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 19 October 2023 18:22 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413CEC17C514 for <cellar@ietfa.amsl.com>; Thu, 19 Oct 2023 11:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8ph3fh2q7K5 for <cellar@ietfa.amsl.com>; Thu, 19 Oct 2023 11:22:29 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224A7C17C512 for <cellar@ietf.org>; Thu, 19 Oct 2023 11:22:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 00D941800D for <cellar@ietf.org>; Thu, 19 Oct 2023 14:22:22 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SJq9FJLIF-iW for <cellar@ietf.org>; Thu, 19 Oct 2023 14:22:21 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2962D1800C for <cellar@ietf.org>; Thu, 19 Oct 2023 14:22:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1697739741; bh=2B2yKq+D8rjuktmBMkZYknXtcm5jmvg5678Uhf+7yWM=; h=From:To:Subject:Date:From; b=mVA2Y7TuhrnFyWmd/8kexlhyEuYL04I3Gs3Qys90Aq7v3Z38VkTsz2rg/8sVuqZeW mz0muvwuCWU28AZhxF/uV+tbpaD6jqczFdwd5anAjMIOdD6uHVvkZOMQ/Xvp1ofAV3 GHygukpAgVwItoUAlBFsxcS2SfS/Q1wnQyJOMr+vspD18pbwwoavmFFbKUTHrAtRhI snjNVYv8+loOEWVUe5srZlgw5oN8GoerbH9VTW3W01E4VVsDJ6ki27NrNuytU3JNi8 LdPi2v6wq6vbsxbN8cqIjde+3dHZ14fjSltFK3mZmsNSPo37LyUVRNWQNy9NkrgXjB ohf5AnjdJTerQ==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2300681 for <cellar@ietf.org>; Thu, 19 Oct 2023 14:22:21 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cellar@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 19 Oct 2023 14:22:21 -0400
Message-ID: <27285.1697739741@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/EkWRZI6N_jXqylwfHcPBrdoLgBo>
Subject: [Cellar] purpose of FLAC RFC --- vs xiph.org
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2023 18:22:34 -0000

Roman, in his AD review, asks why we did not take over the xiph.org
ID registry at: https://xiph.org/flac/id.html

Well.  I thought it was because while we are detailing FLAC in a Matroska
container in sufficient detail in an RFC, appropriate for use in archiving,
we were not intending to take over maintenance of FLAC itself.
(For instance, you can also put FLAC into an OGG container, or an MP4 container)

https://xiph.org/flac/format.html actually seems to disagree with me though.

* community FLAC might continue to evolve
* the archival/RFC version might be a useful subset of what's possible

Maybe I'm wrong, and the FLAC community wants the RFC to be the basis for all
future work.  In which case, taking over that application ID table would be
appropriate.  But, there are then other IANA tables that we need:
* Table 2
* Table 8
* Table 13

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide