Re: [art] [Last-Call] Artart last call review of draft-zern-webp-03

[Ned Freed <[e-mail]>]

> > > 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.

> 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