Some of you may know that the FLAC format is in the process of being formally specified by the IETF as a so-called RFC. 17 months ago I shared here (https://hydrogenaud.io/index.php/topic,123069.0.html) that the working group considered the document finished and issued a working group last call. This resulted in a lot of comments and subsequently improvements. After that, the document was read and commented on by various IETF people, which took a while.
Today I got the message that the document has been formally approved. The announcement is here. (https://mailarchive.ietf.org/arch/msg/ietf-announce/vWolycrCXv3flcsUJXmawAoV4cc/) This means the people in charge (the Internet Engineering Steering Group or IESG) have read the document, suggested changes and finally approved the document. Yay!
However, FLAC isn't described by an official RFC just yet. The current draft will be sent to the RFC Production Center, where an editor will review the document and adjust tone, spelling and grammar for it to read like any other RFC. Looking at the current queue (https://www.rfc-editor.org/current_queue.php) (where Matroska, the ".mkv" container format, is too!) this will probably take a few months up to maybe half a year.
So, I just wanted to share that news with you all. It is not really big news or anything, but I am glad all the technical stuff has been agreed upon and approved.
That's great to hear ktf :)
Great news! Thank you and all members of the work group :)
@ktf, what does it mean for the rest of us?
Joining the choir here!
If I am to speculate about the reasons for FLAC's success, I have a hunch that it was not only about being the right FOSS at the right time, but also an openly available specification.
@ktf, what does it mean for the rest of us?
That depends on who and what you are.
As
@cid42 mentioned (https://hydrogenaud.io/index.php/topic,123069.msg1017152.html#msg1017152) in the previous thread, it makes coding a fresh, independent FLAC decoder a whole lot easier. The document also contains a lot of helpful insights that might make new implementations more compatible. The accompanying test files make validation of a new implementation much easier. So, the direct benefits are for implementers.
For users, this implies an indirect benefit: better implentations to use.
For long term storage (archiving institutions) it is reassurance that the format won't fade into oblivion at some point, because it is specified in a rather official, open, free-access document that can be copied and even stored alongside the content, and is not defined solely by its implementations (that might only work on ancient, fragile hardware at some point) or some expensive spec that nobody buys and thus could be inaccessible in the future.
To follow-up on that, IETF guards their published RFCs - warts'n'all! - to the extent that even if typos are discovered, there is quite some process to even get a "verified" stamp on the "uh-oh": https://www.rfc-editor.org/errata_search.php?eid=1579 .
To the outside world, that is a safety net against hurried changes - like, whatever consequences might otherwise incur by way of a (brain)fart from Elon Musk sniffing a new weed strain. Or another unpublished version of the dreaded ".doc format". Not saying that anyone in the power to do that to the FLAC spec would do so - but by RFC status you can take the IETF's word that any changes will go through a thorough process. Not merely relying on some developer's word for it.
I do have a kinda "formalistic" follow-up question, the IETF has evolved over the years:
FLAC is not infrastructure in the same way as a transfer protocol is, so ... where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
(Surely a private archive might appreciate several of the same objectives as users of an online archive, but that is not my question.)
I do have a kinda "formalistic" follow-up question, the IETF has evolved over the years:
FLAC is not infrastructure in the same way as a transfer protocol is, so ... where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
(Surely a private archive might appreciate several of the same objectives as users of an online archive, but that is not my question.)
Since flac is the most sold lossless format out there the IETF may want to guarantee customers can use their purchase in the future without much knowledge like transcoding.
where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
The IETF consists of working groups. Each working group has a charter which defines the scope. The charter of the CELLAR working group is here (https://datatracker.ietf.org/wg/cellar/about/). As you can see, the charter is not related to the internet at all. I don't know how the working group came to be, because it was formed in 2015 and I only joined in 2021.
Clicking myself from that document up, I think I found pretty much the answer:
Codecs are specifically mentioned within the scope of the "Applications and Real-Time Area", which the CELLAR working group belongs to.
It doesn't exactly say who was responsible for wording the scope that way, but the Area Directors are the Internet Engineering Steering Group members.
And, the IESG itself is responsible for what drafts are going on the "Standards track" - thus apparently: for what works are "on-topic" for the "Standards" status.
Will IETF start cranking out FLAC variants of the software?
No ... IETF doesn't write mail server software, though they specify the standards for e-mail.
(Oh my how many mail servers violate those!)
Ok.