On Wed, Oct 20, 2021 at 9:02 AM Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > Hi Dale, > > > On Tue, Oct 12, 2021 at 8:53 PM Dale R. Worley <worley@xxxxxxxxxxx> wrote: > > > > > > It looked like there was some controversy about this, so I decided to > > > take a look. It does seem to me that if it wants to claim an IETF mime > > > type rather than a vnd. one, at the least the exposition needs to be > > > clarified. > > > > > > The introduction of the draft itself references various features of the > > > encoding but seems to be more oriented toward the connoisseur of image > > > encoding formats than users. The documents are wishy-washy regarding > > > compatibility and extensibility, as if these are current snapshots of > > > something that is expected to evolve organically. > > > > > > For instance, section 4 "Interoperability Considerations" includes "The > > > container is RIFF-based and allows extension via user defined chunks" > > > but does not mention this statement in the referenced document: "Older > > > readers may not support files using the lossless format." > > > > > > If we aren't just assigning a code for a vendor's product, we need to > > > put a stake in the ground that is definitive what the format is and > > > isn't, that we expect to stay in the same place for at least five years. > > > > > > The format is finalized. Lossless and animation were added in 2012 [1] > > and 2013 [2], respectively. The comment is in reference to older > > Android releases [3] as those features were being rolled out. > > Then why is there a problem documenting the format in the RFC, as opposed to > depending on a reference to a web page? > > I'm just not seeing why you're insisting on a standards tree type > defined on a web page. Either switch to vendor or document the format > in the specification. > I don't think a vendor type is best as image/webp has been used unofficially since 2010. The browsers that support the format now rely on this so transitioning to a new one would potentially cause some compatibility issues. If a RFC is a requirement then we can go in that direction. This request came from a suggestion by IANA media types during the attempt to register. I don't know that it has been made a requirement consistently, though. image/avif was registered without one using externally hosted documentation: https://aomediacodec.github.io/av1-avif/ > Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
