On Wed, Oct 20, 2021 at 12:54 PM Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > > > 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. > > I have no idea what you are talking about here. AFAIK browsers have no > knowledge of the registration status of a particular type. (And even if they > did, surely an unregistered type would rank lower than any sort of registered > type.) > > If the name is the concern, I already explained that there's no need to > change it: > > If the issue with this being a vendor registration is that the unfaceted > (no "vnd." prefix) name is already in wide use, well, we have an exception > process for that. RFC 6838 Appendix A states: > > From time to time there may also be cases where a media type with an > unfaceted subtype name has been widely deployed without being > registered. (Note that this includes subtype names beginning with > the "x-" prefix.) If possible, such a media type SHOULD be > reregistered with a proper faceted subtype name, possibly using a > deprecated alias to identify the original name (see Section 4.2.9). > However, if this is not possible, the type can, subject to approval > by both the media types reviewer and the IESG, be registered in the > proper tree with its unfaceted name. > > -- https://mailarchive.ietf.org/arch/msg/art/BohI7gnxqHa2tFHKCyovpycCTyI > > > If a RFC is a requirement then we can go in that direction. > > An RFC is not a requirement. A specification of the format we can be > confident will be available for decades is. A web page on a company > web site doesn't qualify IMO. > That is understandable. If a RFC or other means are deemed required as the outcome of the last call we can determine which is best. For my edification, what / where would be acceptable locations for a specification outside of a RFC on IETF? > > 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/ > > I wasn't the reviewer. IMO that registration should have been rejected. > > Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
