Dec 13th, 2021 meeting topics

Hello everyone,

For our second meeting (Dec 13th, 2021) we have a rather foundational topic
that we need to resolve.

   - Is the public/private chunk attribute still valid. Or rather, should
   its definition change? This comes from Nigel Tao
   <https://github.com/nigeltao> in a GitHub issue discussing how we should
   handle already-common chunks like APNG
   <https://github.com/w3c/PNG-spec/issues/45>. More information can be
   found below.
   - As always, if there are other topics you think we should consider,
   feel free to reply and add them.



*Context of public/private chunk & APNG:*

The existing APNG spec from Mozilla
<https://wiki.mozilla.org/APNG_Specification> introduces the chunks acTL,
fcTL, and fdAT. You'll notice that the second letter of each chunk name is
lowercase, which correctly marks them as private chunks
<https://www.w3.org/TR/2003/REC-PNG-20031110/#5Chunk-naming-conventions>.
The spec wording is clear that there is no functional difference between
public/private chunks--it is only intended to prevent naming collisions.
Following that spec wording, we should rename these chunks to aCTL, fCTL,
and fDAT once they become standard.

(From here on, I'll talk about only acTL/aCTL as a shorthand for all 3 of
these chunks.)

From a practical perspective, this change doesn't matter: Future decoders
will surely recognize both acTL and aCTL as the same thing. And encoders
could start producing aCTL instead of acTL.

But there is a problem. Since current APNG decoders already support acTL
and not aCTL, an encoder would prefer to produce acTL chunks. Further,
there already are many existing APNGs with private chunks. (We established
that APNG support is so ubiquitous that it would be silly *not* to have it
standardized.) It might make sense for us to standardize the chunks as-is
(acTL, fcTL, fdAT).

If we extrapolate this out to an extreme, perhaps all APNGs continue to use
private chunks while the public, standard chunks are never used. Although
minor, this would still represent a divergence between the standard and the
real world. We could work around this by noting the history and say that
while acTL isn't standard, it works the same way as aCTL and is the
preferred method. But if we do that, we might as well just standardize acTL.

And if we do accept standardizing acTL, the private/public bit has a new
meaning. Instead, it would mean "Was this chunk originally proposed as part
of the standard?" That might not be useful-enough information to warrant
the use of the bit. The bit might be better served as "reserved".

Keeping the public/private bit would still prevent name collisions between
standard-origin chunks and private-origin chunks. But that bit never
prevented collisions between two private organizations. (The PNG spec
recognizes this
<https://www.w3.org/TR/2003/REC-PNG-20031110/#12Use-of-private-chunks>.) If
we accept acTL, we might clobber someone else's acTL. Which means the
current intent of preventing name collisions is lost.


There is no 100% correct answer, so I think it warrants discussion.
There are trade-offs either way.

Thanks
-Chris Blume