Subject: [art] Artart last call review of draft-zern-webp-03

From: Henry Thompson via Datatracker <[email-masked]>
Date: Fri, 01 Oct 2021 02:51:49 -0700

Reviewer: Henry Thompson
Review result: Ready with Nits

This short document requests media type registration for "image/webp",
for use with the Google-defined webp image format [1], which uses RIFF
(Resource Interchange File Format) [2] as a container.

It's basically ready to go, but there a few bits left out of the
registration template itself, which should be filled in:

  Person & email address to contact for further information:
  Intended usage:
  Restrictions on usage:
  Author:
  Change controller:

[1] https://chromium.googlesource.com/webm/libwebp/+/refs/heads/main/doc/webp-container-spec.txt
[2] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf

---

From: "Henry S. Thompson" <[email-masked]>
Date: Thu, 07 Oct 2021 08:54:50 +0100

James Zern writes:

> On Fri, Oct 1, 2021 at 2:51 AM Henry Thompson via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
>> Reviewer: Henry Thompson
> Thanks for the review and sorry for missing the fields. I think I
> was using an earlier registration request as an example and didn't
> cross check the rfc. The field names and order should match the
> template from rfc6838#section-5.6 now.
>
> ...
> Please let me know if this is acceptable and the formatting is all right.

Thanks for prompt action, the result looks good to me.

This is now ready to go AFAICS.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: Ned Freed <[email-masked]>
Date: Mon, 11 Oct 2021 08:45:42 -0700 (PDT)

I'm going to start with a thought experiment.

Suppose there was a draft in last call that claimed to specify something like a
cryptographic hash function, symmetric cipher, SNMP MIB, or perhaps even an
application protocol.

However, instead of actually defining this thing, it instead referred the
reader to a couple of web pages - not IETF web pages, but pages owned by the
corporation behind the registration. In fact the only real function of the
document was to assign identifiers owned by the IETF, in effect attaching an
IETF imprimatur to this thing.

In fact the draft didn't even assign change control of the actual
specification to the IETF.

How do you think such a draft would fare? I'm thinking "not very well".

But this is essentially what's being done here. This draft doesn't specify the
image format it is registering. All it really does is register a media type
name in the standards tree for the format, with the IETF being the associated
standards body but not the change controller. 

And it's not like there are no other options. The obvious one is to simply
register this media type in the vendor tree. Easy-peasy, fill in the form
at IANA, no document required.

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.

If for some reason this really needs to be in the standards tree, another
option would be to properly document the format in the RFC. Maybe I'm missing
something, but I don't see why the relevant web pages could not be turned into
RFC text. I also note that the RFC Errata system could then be used to track
any errors that are found.

One final note. The current security considerations in this draft
need work no matter what is done. They currently say:

   Security risks are similar to other media content and may include
   buffer overruns and uninitialized data usage as part of the demuxing
   and decoding process [cve.mitre.org-libwebp] [crbug-security].

Seriously, similar? The issues listed are ones associated with implementation
errors, and that should be explicitly stated. The obvious risk associated with
compressed types is that malicious content can often be constructed that
expanded to something vastly larger than the original. Other potential risks
with image types include the ability to include executable content in the data
stream. (I don't think this is a risk with this particular type, but if so it
should be stated that it isn't.) And it should be noted whether or not the type
itself provides any sort of privacy or integrity protection.

				Ned

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Oct 2021 23:52:58 -0400

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.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Oct 2021 22:47:41 -0400

James Zern <[email-masked]> writes:
> 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.
> RIFF as a container is extensibile, but that would be done at an
> application level and wouldn't affect the implementation of the
> frame's compression. The core chunks to the format are stable and will
> not be changed.

I'm not asking you to explain it *to me*.  I'm saying that the
exposition could use some significant tightening up and clarification.

Dale

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Oct 2021 08:54:34 -0700 (PDT)

> Hi Dale,

> On Tue, Oct 12, 2021 at 8:53 PM Dale R. Worley <[email-masked]> wrote:
> >

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

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Oct 2021 12:37:37 -0700 (PDT)

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

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

---

From: James Zern <[email-masked]>
Date: Fri, 15 Oct 2021 16:33:15 -0700

Hi Dale,

[1] https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v0.2.0/NEWS
[2] https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v0.3.0
[3] https://developer.android.com/guide/topics/media/media-formats#image-formats

---

From: James Zern <[email-masked]>
Date: Wed, 20 Oct 2021 10:38:08 -0700

If a RFC is a requirement then we can go in that direction. This

---

From: James Zern <[email-masked]>
Date: Wed, 20 Oct 2021 10:40:28 -0700

> exposition could use some significant tightening up and clarification.

Thanks for the clarification Dale. It sounds like some of this could
go into the Interoperability Considerations section.

---

From: James Zern <[email-masked]>
Date: Thu, 21 Oct 2021 18:56:25 -0700

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 23 Oct 2021 06:00:19 -0700 (PDT)

> specification outside of a RFC on IETF?

A formal publication of or the web site of another standards body. Of course in
that case it would almost certainly be their standard, not the IETF's.

				Ned