Subject: [Cellar] should flac-specification be informational or standards track

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Feb 2022 10:58:41 -0500

There is a discussion on a PR for FLAC about whether the document should be
standards track or informational.

Our charter actually says it should be standards track. That may be an error.

As previously discussed the document goes back quite a few years to a GNU
Public Documentation document, and has been implemented in many places
already.  (I don't have a list, but maybe someone else does, or maybe it's in
the document already, I didn't look yet)

The usual IETF process, which we are doing with FFv1 is that RFC9043 is
informational.  This specifically means that the IETF did not have the right
to make non-compatible changes to the protocol.  We were simply describing
what was already there.
FFv1 v4 will be standards track, and we could start with a blank slate.

As far as I know, the same situation applies for FLAC.
We are aiming to just describe what is out there.

***
However, I sense that there may be a number of compatible changes that we
might want to document.    Maybe that includes deprecating some existing
practice, but not obsoleting it.  I'm unclear as I'm not an expert here.
***

From a procurement of archival systems point of view, it might be that we
need a suite of standards-track documents.
* EBML is proposed standard,
* Matroska is standards track

and from what I understand, Matroska needs an encoder to go with it.
RFC9043 is Informational.
If FLAC is also Informational, then there is a gap in the standards.
Now, from a purest NAFTA Article 10 (or PETA or CETA or whatever Trump renamed NAFTA
to) point of view, an Informational RFC is not strictly a performance
standard so can't be used in a government RFP.  But, pragmatically, they
never quite figure out that not all RFCs are standards.
If there is a concern like the above (Dave?), then please speak up.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 20 Feb 2022 08:17:16 +0100

> RFC9043 is Informational.

What would qualify to be a proposed standard rather an informational 
document ? Mostly changes to what already exists in the wild ?

For example in the case of EBML we have clarified things that already 
existed but we didn't really add anything what wasn't already there. 
Only the EBML Schema document is new.

For Matroska it's less clear cut as we deprecated a lot of things that 
were not really used. But we shouldn't have done any breaking changes, 
as that's the whole point of being compatible with what exists. I think 
we have added a few elements since we started the whole IETF process. So 
it may qualify as standardization of new things in the format.

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Martijn van Beurden <[email-masked]>
Date: Mon, 21 Feb 2022 20:17:08 +0100

> If there is a concern like the above (Dave?), then please speak up.

First, let me say I'm curious about the "Do we need FLAC to be a
standards track document" question so I hope this mail doesn't derail
that discussion.

However, *if* it turns out FLAC *should* be a standards track document
for some reason and *if* in that case it turns out the document *must*
document something new, would implementing a large, non-trivial
addition relevant to the archival community be enough to regard it as
such?

I think there is enough reserved room in the FLAC specification to
allow extension to implement coding of 32-bit floating point audio
data. This would include specifying suitable new residual coding
methods and specifying the handling of float data as separate
(integer) exponent and significand components. This is backwards
compatible in the sense that all non-float data would still be coded
in a way compatible with existing decoders, but float data would be
coded in a way that existing decoders know they should not try to
decode, but in fact need an upgrade to do so? 32-bit floating point
audio data is relevant in that it is often used in audio mixing, and
might be a format a (pre-) master is stored in.

Another possible extensions relevant for the archival community would
be storage of DSD (pulse density modulated data), for archival of SACD
data for example.

Kind regards, Martijn van Beurden

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 21 Feb 2022 20:14:19 -0600

Dear All,

As you're beginning to suspect, the line between Informational and
Standards-Track isn't THAT clear.

As Michael said, one model when the IETF gets change control for a protocol
that exists outside the IETF, is that you publish a descriptive document as
a baseline, and then start publishing Standards Track documents from that
point on. But we don't have to do it that way - usually we do it that way,
because the version that exists outside the IETF is perceived as
insufficient in some way, so we want to document it, but we don't want to
encourage people to deploy that version further by publishing it as
Standards Track.

The good news is that ultimately, we can (and should) dump questions like
this on our AD. If we have a strong inclination one way or another, for
reasons that we're starting to discuss, we should tell him that, but we
don't have to figure this out now.

I'll add it to the agenda for tomorrow's meeting, and we can level-set.

Best,

Spencer

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Feb 2022 11:23:30 -0500

> addition relevant to the archival community be enough to regard it as

No, that's not required.
It doesn't have to document something "new", and no we wouldn't need to make
up some silly extension like that.

A critical question is whether or not we can change something old :-)
Maybe we would be wise not to.

Maybe Murray will have a few minutes to join the WG meeting this afternoon.

---

From: Jerome Martinez <[email-masked]>
Date: Wed, 23 Feb 2022 19:30:20 +0100

On 22/02/2022 03:14, Spencer Dawkins at IETF wrote:
> The good news is that ultimately, we can (and should) dump questions 
> like this on our AD. If we have a strong inclination one way or 
> another, for reasons that we're starting to discuss, we should tell 
> him that, but we don't have to figure this out now.

As the person who commented about this topic on the PR, I was worried 
about the status from the point of view from IETF but if IETF is fine 
with "standard", it is fine for me too.

Jérôme

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Feb 2022 11:15:41 -0600

Hi, Michael and Murray,

> with "standard", it is fine for me too.

https://datatracker.ietf.org/wg/cellar/about/ has "Submit specification for
FLAC audio codec to IESG (Standards Track)", so I think this is "no action
required from the co-chairs or AD".

Best,

Spencer