WebP Image Format
draft-zern-webp-15

[Ballot comment]
Thank you to Thomas Fossati for the GENART review.

I previously balloted on version -09 of this document.  Thank you for addressing a many of my COMMENTs.

** Section 2.7.1.2.  The “Pre-processing (P)” flag is two bits but only has two values.  It was intentional (perhaps for future extensibility) allocated the extra bit?

[Ballot comment]
# Internet AD comments for draft-zern-webp-14
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S2.7

* There's a 'VP8' in paragraph with a run of chuck types that could perhaps
  be 'VP8 ' to match the explicit space character style used elsewhere in
  the doc?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-zern-webp-13; we had also reviewed draft-zern-webp-09 and draft-zern-webp-03 during previous Last Calls. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there is a single action which we must complete.

In the image media type registry in the Media Types registry group located at:

https://www.iana.org/assignments/media-types/

a new registration is to be made as follows:

Name: webp
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-15):

From: The IESG
To: IETF-Announce
CC: draft-zern-webp@ietf.org, shodoco@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (WebP Image Format) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'WebP Image Format'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

NOTE:
This document was previously approved for publication by the IESG.  However,
due to substantial changes made during AUTH48, the decision was made to do
a second Last Call before resuming the publication process.


Abstract


  This document defines the WebP image format and registers a media
  type supporting its use.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-zern-webp/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5840/
  https://datatracker.ietf.org/ipr/5841/
  https://datatracker.ietf.org/ipr/5842/
  https://datatracker.ietf.org/ipr/5843/
  https://datatracker.ietf.org/ipr/5844/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    This document requests Informational status.  This is not the product of a working group, and the technical work was developed outside of the IETF.  The document’s main purpose is to define the WebP image format and make a standard media type registration.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
    This document defines the WebP image format, and considers its registration of the media type image/webp.

Working Group Summary:
    The document is not a product of a working group, and is sponsored by an Area Director.  Discussion has occurred on the DISPATCH and MEDIA-TYPES lists.

    This document was previously approved by the IESG, but during AUTH48 so many changes were made that it was decided to send it for a second
    IETF Last Call before returning it to the IESG or, possibly, directly to the RFC Editor queue.

Document Quality:
    The document provides detailed specifications for the WebP image format.  Several people have reviewed it and provided useful feedback.

Personnel:
  Document Shepherd: Huapeng Zhou
  Responsible Area Director: Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    The shepherd did a review of the document and feels it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
    The shepherd does not have any concerns about the level of reviews performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
    The document does not require any particular reviews, given its main purpose of media type definition and registration.  It has had a preliminary review by a media types designated expert.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
    The shepherd does not have any concern or issue with this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
    The sole author has confirmed the above.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
    No IPR disclosure has been filed referencing that document.

    [Area Director note: As of -11, there are five IPR claims asserted by Google.  All of them are accompanied by general licensing terms that do not encumber implementations.  As this is a
    sponsored document, there is no WG in which to hold discussion about any further concerns; AD review stands in place of that requirement.]


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
    The document is not a product of a working group, but rather is being sponsored by an Area Director.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
    No one has threatened to appeal.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
    All the nits identified by the shepherd have been addressed or would be addressed in the next revision per author confirmation.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
    The document only requires review for media type definition and allocation. A first level of review has been conducted by a media types designated expert.


(13) Have all references within this document been identified as either normative or informative?
    Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
    There are two normative references to external Chromium documentation, which is not subject to IETF change control. 


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
    No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
    Publication of this document will not change the status of any document. This is correctly identified in the title page header.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
    This document does not define any protocol extension.  The newly created IANA registry includes a detailed specification of the initial contents for the registry, and a reasonable name for the new registry has been suggested.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
    No new registries are created by this document.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
    This is not applicable.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
    This is not applicable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    This document requests Informational status.  This is not the product of a working group, and the technical work was developed outside of the IETF.  The document’s main purpose is to define the WebP image format and make a standard media type registration.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
    This document defines the WebP image format, and considers its registration of the media type image/webp.

Working Group Summary:
    The document is not a product of a working group, and is sponsored by an Area Director.  Discussion has occurred on the DISPATCH and MEDIA-TYPES lists.

Document Quality:
    The document provides detailed specifications for the WebP image format.  Several people have reviewed it and provided useful feedback.

Personnel:
  Document Shepherd: Huapeng Zhou
  Responsible Area Director: Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    The shepherd did a review of the document and feels it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
    The shepherd does not have any concerns about the level of reviews performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
    The document does not require any particular reviews, given its main purpose of media type definition and registration.  It has had a preliminary review by a media types designated expert.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
    The shepherd does not have any concern or issue with this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
    The sole author has confirmed the above.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
    No IPR disclosure has been filed referencing that document.

    [Area Director note: As of -11, there are five IPR claims asserted by Google.  All of them are accompanied by general licensing terms that do not encumber implementations.  As this is a
    sponsored document, there is no WG in which to hold discussion about any further concerns; AD review stands in place of that requirement.]


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
    The document is not a product of a working group, but rather is being sponsored by an Area Director.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
    No one has threatened to appeal.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
    All the nits identified by the shepherd have been addressed or would be addressed in the next revision per author confirmation.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
    The document only requires review for media type definition and allocation. A first level of review has been conducted by a media types designated expert.


(13) Have all references within this document been identified as either normative or informative?
    Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
    There are two normative references to external Chromium documentation, which is not subject to IETF change control. 


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
    No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
    Publication of this document will not change the status of any document. This is correctly identified in the title page header.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
    This document does not define any protocol extension.  The newly created IANA registry includes a detailed specification of the initial contents for the registry, and a reasonable name for the new registry has been suggested.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
    No new registries are created by this document.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
    This is not applicable.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
    This is not applicable.

Being returned to the authors to restart normal processing, including a second pass through Last Call and an IESG Evaluation, as the delta between the AUTH48 version and the version approved by the IESG was much too large for comfort.

[Ballot comment]

# Paul Wouters, SEC AD, comments for draft-zern-webp-09
CC @paulwouters

My DISCUSSes were resolved.
Although not secure why the Security Considerations doesn't mention remote code execution on the webserver side, which is a much more critical issue that "crashes" or "information leaks"


## DISCUSS (old)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Relationship between RFC and source code reference

I support the DISCUSS by Robert Wilton on the relationship between
RFC and source code.

        Note this section is based on the documentation in the libwebp source

The document should claim to be the specification. It can refer to other things, but
saying that the section is based on something else leaves room to interpret that if
the something else changes, that this document somehow also changes. But that is not
how RFCs work.

### Missing IPR statements

I also support the DISCUSS by Éric Vyncke about the two missing IPR statements.


### SECDIR review comment on security
 
I support the SECDIR review comment of Roman Danyliw, and actually am raising it
as a DISCUSS. The number of CVEs on ImageMagick used on clients and servers is
pretty large, and a strong note on security to implementers is very much needed.

### Normative language issues

A large number of places in the text seem to not handle SHOULD vs
MUST or MAY properly, eg:

  The data payload.  If _Chunk Size_ is odd, a single padding
  byte -- that SHOULD be 0 to conform with RIFF [riff-spec] --
  is added.  Applications MAY use another value, but readers
  may fail to parse the file.

Why not say, "MUST be 0 and MUST be ignored if not 0" ?

What would be a good reason for not following the SHOULD ?

  The file SHOULD NOT
  contain anything after it.  Readers MAY parse such files, ignoring
  the trailing data.

Again, why not MUST NOT contain, and MUST ignore trailing data?
(more of these issues are present in the document)

          Future specifications MAY add more fields.

Why use MAY here in capitals? And why not say what really matters, eg
that one may encounter unknown fields and these must be ignored.

  This chunk MUST appear if the _Animation_ flag in the VP8X chunk is
  set.  If the _Animation_ flag is not set and this chunk is present,
  it SHOULD be ignored.

Why not MUST be ignored?
What should be done if the chunk that MUST be there, is not there?

A number of reserved fields say "MUST be 0." and should be extended to say "MUST be 0
and MUST be ignored if not 0" so that future updates to these fields are possible
without breaking existing clients.

### pseudo code license

Should the pseudo code be in proper quote tags so it will be released under the appopriate license ?

## COMMENTS

### not following convention without explanation

  *Note:* RIFF has a convention that all-uppercase chunk FourCCs are
  standard chunks that apply to any RIFF file format, while FourCCs
  specific to a file format are all lowercase.  WebP does not follow
  this convention.

Why not?
Why not explain in the document why not?

### A name with a trailing space is bad

Instead of "VP8 ", why not use a non-space character to avoid weirdness
and confusion. Since both lossy and lossless start with an 'l', maybe
use 'VP8y' for lossy ?

### handwaving to GIF spec

        Many tools
        and browsers assign a minimum duration similar to GIF.

Why not just give the minimum number so implementers don't need to look at the GIF spec?


### Bit assumed to be 0 ?

    Compression method (C): 2 bits
          The compression method used:

          *  0: No compression.

          *  1: Compressed using the WebP lossless format.

This only describes one of the two bits ? Is the other always 0? If so please specify that.
If not, there is a bigger issue.

### account for future new chunks in the text

  A RIFF chunk (described in Section 2.2.) whose _chunk tag_ is
  different from any of the chunks described in this section, is
  considered an _unknown chunk_.

Can this be made more general by saying "Any RIFF chunk whose _chunk tag_
is unknown by the implementation is considered an _unknown chunk_." ?


## NITS:

### *stars are unclear*

The use of *'s in the text "*Note:*" makes it just more unreadable. Just use "Note:".

[Ballot comment]
CC @evyncke

Thank you for the work put into this document. I have now cleared my blocking DISCUSS (thanks to the authors and to Murray).

Please find below *only for archiving* two blocking DISCUSS points (already address), some non-blocking COMMENT points.

Special thanks to Huapeng Zhou for the shepherd's detailed write-up including the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## Previous DISCUSS for archiving purpose only

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### IANA section

I was unable to find the entry in the table as claimed by:
```
  IANA has updated the "Image Media Types" registry [IANA-Media-Types]
  to include 'image/webp' as described in Section 6.1.
```

Suggest to use the correct RFC 8216 language.

### Shepherd's write-up

```
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?
    The sole author has confirmed the above.
```

But there are three authors ;-)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    This document requests Informational status.  This is not the product of a working group, and the technical work was developed outside of the IETF.  The document’s main purpose is to define the WebP image format and make a standard media type registration.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
    This document defines the WebP image format, and considers its registration of the media type image/webp.

Working Group Summary:
    The document is not a product of a working group, and is sponsored by an Area Director.  Discussion has occurred on the DISPATCH and MEDIA-TYPES lists.

Document Quality:
    The document provides detailed specifications for the WebP image format.  Several people have reviewed it and provided useful feedback.

Personnel:
  Document Shepherd: Huapeng Zhou
  Responsible Area Director: Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    The shepherd did a review of the document and feels it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
    The shepherd does not have any concerns about the level of reviews performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
    The document does not require any particular reviews, given its main purpose of media type definition and registration.  It has had a preliminary review by a media types designated expert.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
    The shepherd does not have any concern or issue with this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
    The sole author has confirmed the above.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
    No IPR disclosure has been filed referencing that document.

    [Area Director note: As of -11, there are five IPR claims asserted by Google.  All of them are accompanied by general licensing terms that do not encumber implementations.  As this is a
    sponsored document, there is no WG in which to hold discussion about any further concerns; AD review stands in place of that requirement.]


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
    The document is not a product of a working group, but rather is being sponsored by an Area Director.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
    No one has threatened to appeal.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
    All the nits identified by the shepherd have been addressed or would be addressed in the next revision per author confirmation.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
    The document only requires review for media type definition and allocation. A first level of review has been conducted by a media types designated expert.


(13) Have all references within this document been identified as either normative or informative?
    Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
    There are two normative references to external Chromium documentation, which is not subject to IETF change control. 


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
    No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
    Publication of this document will not change the status of any document. This is correctly identified in the title page header.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
    This document does not define any protocol extension.  The newly created IANA registry includes a detailed specification of the initial contents for the registry, and a reasonable name for the new registry has been suggested.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
    No new registries are created by this document.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
    This is not applicable.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
    This is not applicable.

[Ballot comment]
# GEN AD review of draft-zern-webp-09

CC @larseggert

Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/SDEy8W3nAqxD3CaEmuxlVe5zy4w).

## Comments

### Section 2.5, paragraph 7
```
    Note the fourth character in the 'VP8 ' fourcc is an ASCII space
    (%x20).
```
"%x20" is an unusual syntax, wouldn't "0x20" be much more familiar to
  readers? Especially since later sections of this document use the
  0x notation anyway.

### Section 2.6, paragraph 3
```
    This layout SHOULD be used if the image requires lossless encoding
    (with an optional transparency channel) and does not require advanced
    features provided by the extended format.
```
Should the SHOULD not be a MUST? Otherwise, when would it make sense
to not do so? (See Paul's DISCUSS; this is a prevalent issue in the
document.)

### Section 2.7, paragraph 15
```
    All chunks SHOULD be placed in the same order as listed above.  If a
    chunk appears in the wrong place, the file is invalid, but readers
    MAY parse the file, ignoring the chunks that come too late.
```
By "come too late" I assume you mean "are out of order"?

### Section 2.7, paragraph 15
```
    *Rationale:* Setting the order of chunks should allow quicker file
    parsing.  For example, if an 'ALPH' chunk does not appear in its
    required position, a decoder can choose to stop searching for it.
    The rule of ignoring late chunks should make programs that need to do
    a full search give the same results as the ones stopping early.
```
This seems fragile. Is this really needed?

### Section 2.7, paragraph 27
```
    The product of _Canvas Width_ and _Canvas Height_ MUST be at most
    2^32 - 1.
```
What happens otherwise? (See Paul's DISCUSS; this is a prevalent issue
in the document.)

### Section 2.7.1.1, paragraph 7
```
            *  Background color MAY contain a transparency value (alpha),
                even if the _Alpha_ flag in VP8X chunk (Section 2.7,
                Paragraph 9) is unset.
```
Since it's defined as a unit32, it *will* always contain an alpha value.

### Section 7, paragraph 22
```
    [riff-spec]
                "Multimedia Programming Interface and Data Specifications
                1.0", .
```
HTTP URL above redirects to HTTPS with a bad cert. Not great.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.5, paragraph 7
```
-    Note the fourth character in the 'VP8 ' fourcc is an ASCII space
-                                            ^  ^^
+    Note the fourth character in the 'VP8 ' FourCC is an ASCII space
+                                            ^  ^^
```

#### Section 2.7.1.5, paragraph 10
```
-    Note the fourth character in the 'XMP ' fourcc is an ASCII space
-                                            ^  ^^
+    Note the fourth character in the 'XMP ' FourCC is an ASCII space
+                                            ^  ^^
```

### URLs

These URLs in the document did not return content:

* http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf

### Grammar/style

#### Section 1, paragraph 4
```
(color profile, metadata, animation etc) with other formats as well. This s
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 2.7.1.2, paragraph 26
```
ept the first one. Also, a file may possibly contain both 'EXIF' and 'XMP ' c
                                ^^^^^^^^^^^^
```
Consider using "may", "possibly".

#### Section 2.7.2, paragraph 4
```
gnificant bits of the original data. Thus the statement b = ReadBits(2); is
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 3.2, paragraph 6
```
ndicating the end-of-transforms. Typically an encoder would use these transf
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 3.5.2, paragraph 9
```
n only be used when there are a small number of unique values. color_table_s
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 3.5.2, paragraph 10
```
specifies how many pixels are combined together: int width_bits; if (color_t
                              ^^^^^^^^^^^^^^^^^
```
"combined together" is redundant. Use "combined". (Also elsewhere.)

#### Section 3.5.2, paragraph 12
```
t eight pixels are combined together and each pixel has a range of [0..1], i
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3.5.3, paragraph 1
```
5. Color indexing image: An array of of size color_table_size (up to 256 ARG
                                  ^^^^^
```
Possible typo: you repeated a word.

#### Section 3.5.4, paragraph 2
```
cently seen color. The following sub-sections describe each of these in detai
                                ^^^^^^^^^^^^
```
This word is normally spelled as one. (Also elsewhere.)

#### Section 3.7.2.2, paragraph 8
```
extended in the format's early stages so some older readers may not support l
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# GEN AD review of draft-zern-webp-09

CC @larseggert

Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/SDEy8W3nAqxD3CaEmuxlVe5zy4w).

## Discuss

### Section 2.7, paragraph 26
```
    Future specifications MAY add more fields.
```
How would that happen? I can see how reserved bits can become used,
but since this header doesn't seem to have a version field, how would
you define new fields and allow backwards compatibility?

### Section 2.7.2, paragraph 2
```
    Displaying an _animated image_ canvas MUST be equivalent to the
    following pseudocode:
```
Pseudocode can illustrate the specified algorithm, but it can't
replace a textual description of what the algorithm is. Especially
since the pseudocode here uses a ton of otherwise not described
functions and variables.

[Ballot comment]
## Comments

### Section 2.5, paragraph 7
```
    Note the fourth character in the 'VP8 ' fourcc is an ASCII space
    (%x20).
```
"%x20" is an unusual syntax, wouldn't "0x20" be much more familiar to
  readers? Especially since later sections of this document use the
  0x notation anyway.

### Section 2.6, paragraph 3
```
    This layout SHOULD be used if the image requires lossless encoding
    (with an optional transparency channel) and does not require advanced
    features provided by the extended format.
```
Should the SHOULD not be a MUST? Otherwise, when would it make sense
to not do so? (See Paul's DISCUSS; this is a prevalent issue in the
document.)

### Section 2.7, paragraph 15
```
    All chunks SHOULD be placed in the same order as listed above.  If a
    chunk appears in the wrong place, the file is invalid, but readers
    MAY parse the file, ignoring the chunks that come too late.
```
By "come too late" I assume you mean "are out of order"?

### Section 2.7, paragraph 15
```
    *Rationale:* Setting the order of chunks should allow quicker file
    parsing.  For example, if an 'ALPH' chunk does not appear in its
    required position, a decoder can choose to stop searching for it.
    The rule of ignoring late chunks should make programs that need to do
    a full search give the same results as the ones stopping early.
```
This seems fragile. Is this really needed?

### Section 2.7, paragraph 27
```
    The product of _Canvas Width_ and _Canvas Height_ MUST be at most
    2^32 - 1.
```
What happens otherwise? (See Paul's DISCUSS; this is a prevalent issue
in the document.)

### Section 2.7.1.1, paragraph 7
```
            *  Background color MAY contain a transparency value (alpha),
                even if the _Alpha_ flag in VP8X chunk (Section 2.7,
                Paragraph 9) is unset.
```
Since it's defined as a unit32, it *will* always contain an alpha value.

### Section 7, paragraph 22
```
    [riff-spec]
                "Multimedia Programming Interface and Data Specifications
                1.0", .
```
HTTP URL above redirects to HTTPS with a bad cert. Not great.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.5, paragraph 7
```
-    Note the fourth character in the 'VP8 ' fourcc is an ASCII space
-                                            ^  ^^
+    Note the fourth character in the 'VP8 ' FourCC is an ASCII space
+                                            ^  ^^
```

#### Section 2.7.1.5, paragraph 10
```
-    Note the fourth character in the 'XMP ' fourcc is an ASCII space
-                                            ^  ^^
+    Note the fourth character in the 'XMP ' FourCC is an ASCII space
+                                            ^  ^^
```

### URLs

These URLs in the document did not return content:

* http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf

### Grammar/style

#### Section 1, paragraph 4
```
(color profile, metadata, animation etc) with other formats as well. This s
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 2.7.1.2, paragraph 26
```
ept the first one. Also, a file may possibly contain both 'EXIF' and 'XMP ' c
                                ^^^^^^^^^^^^
```
Consider using "may", "possibly".

#### Section 2.7.2, paragraph 4
```
gnificant bits of the original data. Thus the statement b = ReadBits(2); is
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 3.2, paragraph 6
```
ndicating the end-of-transforms. Typically an encoder would use these transf
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 3.5.2, paragraph 9
```
n only be used when there are a small number of unique values. color_table_s
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 3.5.2, paragraph 10
```
specifies how many pixels are combined together: int width_bits; if (color_t
                              ^^^^^^^^^^^^^^^^^
```
"combined together" is redundant. Use "combined". (Also elsewhere.)

#### Section 3.5.2, paragraph 12
```
t eight pixels are combined together and each pixel has a range of [0..1], i
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3.5.3, paragraph 1
```
5. Color indexing image: An array of of size color_table_size (up to 256 ARG
                                  ^^^^^
```
Possible typo: you repeated a word.

#### Section 3.5.4, paragraph 2
```
cently seen color. The following sub-sections describe each of these in detai
                                ^^^^^^^^^^^^
```
This word is normally spelled as one. (Also elsewhere.)

#### Section 3.7.2.2, paragraph 8
```
extended in the format's early stages so some older readers may not support l
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# Paul Wouters, SEC AD, comments for draft-zern-webp-09
CC @paulwouters



## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Relationship between RFC and source code reference

I support the DISCUSS by Robert Wilton on the relationship between
RFC and source code.

        Note this section is based on the documentation in the libwebp source

The document should claim to be the specification. It can refer to other things, but
saying that the section is based on something else leaves room to interpret that if
the something else changes, that this document somehow also changes. But that is not
how RFCs work.

### Missing IPR statements

I also support the DISCUSS by Éric Vyncke about the two missing IPR statements.


### SECDIR review comment on security
 
I support the SECDIR review comment of Roman Danyliw, and actually am raising it
as a DISCUSS. The number of CVEs on ImageMagick used on clients and servers is
pretty large, and a strong note on security to implementers is very much needed.

### Normative language issues

A large number of places in the text seem to not handle SHOULD vs
MUST or MAY properly, eg:

  The data payload.  If _Chunk Size_ is odd, a single padding
  byte -- that SHOULD be 0 to conform with RIFF [riff-spec] --
  is added.  Applications MAY use another value, but readers
  may fail to parse the file.

Why not say, "MUST be 0 and MUST be ignored if not 0" ?

What would be a good reason for not following the SHOULD ?

  The file SHOULD NOT
  contain anything after it.  Readers MAY parse such files, ignoring
  the trailing data.

Again, why not MUST NOT contain, and MUST ignore trailing data?
(more of these issues are present in the document)

          Future specifications MAY add more fields.

Why use MAY here in capitals? And why not say what really matters, eg
that one may encounter unknown fields and these must be ignored.

  This chunk MUST appear if the _Animation_ flag in the VP8X chunk is
  set.  If the _Animation_ flag is not set and this chunk is present,
  it SHOULD be ignored.

Why not MUST be ignored?
What should be done if the chunk that MUST be there, is not there?

A number of reserved fields say "MUST be 0." and should be extended to say "MUST be 0
and MUST be ignored if not 0" so that future updates to these fields are possible
without breaking existing clients.

### pseudo code license

Should the pseudo code be in proper quote tags so it will be released under the appopriate license ?

[Ballot comment]
## COMMENTS

### not following convention without explanation

  *Note:* RIFF has a convention that all-uppercase chunk FourCCs are
  standard chunks that apply to any RIFF file format, while FourCCs
  specific to a file format are all lowercase.  WebP does not follow
  this convention.

Why not?
Why not explain in the document why not?

### A name with a trailing space is bad

Instead of "VP8 ", why not use a non-space character to avoid weirdness
and confusion. Since both lossy and lossless start with an 'l', maybe
use 'VP8y' for lossy ?

### handwaving to GIF spec

        Many tools
        and browsers assign a minimum duration similar to GIF.

Why not just give the minimum number so implementers don't need to look at the GIF spec?


### Bit assumed to be 0 ?

    Compression method (C): 2 bits
          The compression method used:

          *  0: No compression.

          *  1: Compressed using the WebP lossless format.

This only describes one of the two bits ? Is the other always 0? If so please specify that.
If not, there is a bigger issue.

### account for future new chunks in the text

  A RIFF chunk (described in Section 2.2.) whose _chunk tag_ is
  different from any of the chunks described in this section, is
  considered an _unknown chunk_.

Can this be made more general by saying "Any RIFF chunk whose _chunk tag_
is unknown by the implementation is considered an _unknown chunk_." ?


## NITS:

### *stars are unclear*

The use of *'s in the text "*Note:*" makes it just more unreadable. Just use "Note:".

[Ballot discuss]
Hi,

Thanks for this document.  I have one discuss level issue that I would like to further understand and for the document to be clear on what its scope is and how it relates to the libwebp source repository.

(1) p 2, sec 2.  WebP Container Specification

  Note this section is based on the documentation in the libwebp source
  repository [webp-riff-src] at the time of writing.

It isn't really clear to me whether this RFC is the primary reference for this media registration, or whether the libwebp source repository is, and this just represents a snapshot at one point in time.  I.e., what does it mean if these two refrences diverge, or there are non-backwards-compatible bugfixes or clarifications made to the WebP source repository.  Which is the definitive version that implementors should use to base their implementation of?

[Ballot comment]
I also have some minor comments:

(2) p 4, sec 2.3.  RIFF File Format

  Chunk Size: 32 bits (_uint32_)
          The size of the chunk not including this field, the chunk
          identifier or padding.

Probably helpful to say what the units are here.


(3) p 4, sec 2.3.  RIFF File Format

  Chunk Payload: _Chunk Size_ bytes
          The data payload.  If _Chunk Size_ is odd, a single padding
          byte -- that SHOULD be 0 to conform with RIFF [riff-spec] --
          is added.  Applications MAY use another value, but readers
          may fail to parse the file.

I don't think that the MAY is useful/correct here.  I.e., either readers are required to tolerate any value or they are not.  I think that you would be better to change the SHOULD to a MUST.


(4) p 5, sec 2.4.  WebP File Header

  The file SHOULD NOT contain anything after it.

I read this as saying the file should not contain any data after the WEBP FourCC, which I doubt is what you are intended.  Please expand this to indicate that the file shouldn't contain any data (trailing garbage) beyond the date specified by the "File Size" field.


(5) p 8, sec 2.7.  Extended File Format

  All chunks SHOULD be placed in the same order as listed above.  If a
  chunk appears in the wrong place, the file is invalid, but readers
  MAY parse the file, ignoring the chunks that come too late.

I think that it would be better to change the SHOULD to a MUST.  E.g., following along the lines of draft-iab-protocol-maintenance

Thanks,
Rob

[Ballot discuss]
Thanks for this document. I have one concern, about a couple of the references, which I think (hope) should be easy to resolve.

  [webp-lossless-src]
              Alakuijala, J., "WebP Lossless Bitstream Specification",
              September 2014, .

  [webp-riff-src]
              Google LLC, "WebP RIFF Container", April 2018, .

As an aside, I don't get how the publication dates are even vaguely realistic, considering that both of the references are to main and both have been updated within the last few weeks -- so I'd think 2022 would be the right publication date?

But the real concern is that the references are to main, which is a moving target. The RFC Style Guide, RFC 7322, says:

4.8.6.1.  URIs in RFCs

  The use of URIs in references is acceptable, as long as the URI is
  the most stable (i.e., unlikely to change and expected to be
  continuously available) and direct reference possible.  The URI will
  be verified as valid during the RFC editorial process.

  If a dated URI (one that includes a timestamp for the page) is
  available for a referenced web page, its use is required.

  Note that URIs may not be the sole information provided for a
  reference entry.
 
The easiest fix would seem to be to tag both referenced files, then reference the tagged version?

[Ballot comment]
Thanks for the specification.

I am supporting Eric's discuss.

I have following comments, I believe addressing them would improve this specification -

  - Section 2 and section 3 are written based on the libwebp source repository. It is not clear to me what would happen if the libwebp changes, which description the implementer of WebP media type would follow?

  - who are "readers" and "writers" in this specification? I think it would be great if we can define/describe them someway in this specification. In section 2.7.1.6, can this writer be some sort of relay? from whom it receives the unknown chunks and how does it know if it is allowed to modify the chunks? there is a normative SHOULD in the text and to comply with that, there should be enough description of this writer.

[Ballot comment]
Thank you for the SECDIR review by Tero Kivinen.  I concur highlighting the need for defensive programming.  Consider the following for Section 4 (synthesized with the SECDIR review):

OLD
Security risks are similar to other media content and may include
  integer overflows, out-of-bounds reads and writes to both heap and
  stack, uninitialized data usage, null pointer references, resource
  (disk, memory) exhaustion and extended resource usage (long running
  time) as part of the demuxing and decoding process. 

NEW
Implementations of this format face security risks such as integer overflows, out-of-bounds reads and writes to both heap and stack, uninitialized data usage, null pointer references, resource (disk, memory) exhaustion and extended resource usage (long running time) as part of the demuxing and decoding process.  In particular, implementations reading this format are likely to take input from unknown and possibly unsafe sources – both clients (e.g., web browsers, email clients) and servers (e.g., applications which accepted uploaded images).

** Convert channel

-- Section 2.4: “The file SHOULD NOT contain anything after it.  Readers MAY parse such files, ignoring  the trailing data.”

-- Section 2.7.1.6: “A file MAY contain unknown chunks: … Readers SHOULD ignore these chunks.”

Does this imply that a covert channel could be supported?

** Section 2.*: Mandatory to Implement (MTI) for readers.

-- Section 2.5: “Files with this layout are smaller and supported by older software.”
-- Section 2.7: “*Note:* Older readers may not support files using the extended format.”

Is there an expected MTI for readers?  Would one expect support for both lossy and lossless formats?  All of the document sub-chunk types here?

** Section 2.7.1.2.  The “Pre-processing (P)” flag is two bits but only has two values.  It was intentional (perhaps for future extensibility) allocated the extra bit?

** Section 2.7.1.5.  Please make [ICC], [Exif] and [XMP] normative references.

** Section 3.1.
  Decoding speeds faster than PNG have
  been demonstrated, as well as 25% denser compression than can be
  achieved using today's PNG format

Is there a reference for this performance benchmark?

** Section 3.2.
  In this section, we extensively use C programming language syntax to
  describe the bitstream

Please a reference to the C programming language.  Possibly, C18:

  [ISO.9899.2018]
  International Organization for Standardization,
  "Programming languages - C", ISO Standard 9899, 2018.

** Section 3.3.  For LZ77, please provide a reference.  Possibly:

Ziv, Jacob; Lempel, Abraham. "A Universal Algorithm for Sequential Data Compression". IEEE Transactions on Information Theory. Volume 23, Issue 3:, pages 337–343. May 1977.  DOI: 10.1109/TIT.1977.1055714.  https://ieeexplore.ieee.org/document/1055714

** Section 3.8.  Please cite BNF.  Perhaps, RFC5234?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-zern-webp-09
CC @evyncke

Thank you for the work put into this document.

Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points.

Special thanks to Huapeng Zhou for the shepherd's detailed write-up including the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### IANA section

I was unable to find the entry in the table as claimed by:
```
  IANA has updated the "Image Media Types" registry [IANA-Media-Types]
  to include 'image/webp' as described in Section 6.1.
```

Suggest to use the correct RFC 8216 language.

### Shepherd's write-up

```
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?
    The sole author has confirmed the above.
```

But there are three authors ;-)

[Ballot comment]
## COMMENTS

### Too many details ?

I wonder why the document goes in so many details for the encoding if its only function is `Media Type Registration` per title and abstract. This is quite misleading for the readers even if the good is well done and useful. ***Strongly suggest to change abstract and title*** to reflect the content.

### Abstract

Abstract should be short, but this one is really too terse. Please at least describe what webp is...

### Figure number

It would be nice to number all figures (i.e., the frame formats).

### Section 2

`at the time of writing.` won't age well. Suggest to replace by "in September 2022".

### Section 2.7.1.1

`Reserved: 6 bits MUST be 0.` may the reader assume that those bits MUST be ignored by the decoder ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-zern-webp-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the image namespace of the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a new registration will be made as follows:

Name: webp
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

NOTE: IANA has received a request from an RFC 6838 author and designated expert for media types that the following field be omitted from templates published in I-Ds and RFCs:

Provisional registration? (standards tree only):

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    This document requests Informational status.  This is not the product of a working group, and the technical work was developed outside of the IETF.  The document’s main purpose is to define the WebP image format and make a standard media type registration.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
    This document defines the WebP image format, and considers its registration of the media type image/webp.

Working Group Summary:
    The document is not a product of a working group, and is sponsored by an Area Director.  Discussion has occurred on the DISPATCH and MEDIA-TYPES lists.

Document Quality:
    The document provides detailed specifications for the WebP image format.  Several people have reviewed it and provided useful feedback.

Personnel:
  Document Shepherd: Huapeng Zhou
  Responsible Area Director: Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    The shepherd did a review of the document and feels it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
    The shepherd does not have any concerns about the level of reviews performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
    The document does not require any particular reviews, given its main purpose of media type definition and registration.  It has had a preliminary review by a media types designated expert.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
    The shepherd does not have any concern or issue with this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
    The sole author has confirmed the above.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
    No IPR disclosure has been filed referencing that document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
    The document is not a product of a working group, but rather is being sponsored by an Area Director.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
    No one has threatened to appeal.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
    All the nits identified by the shepherd have been addressed or would be addressed in the next revision per author confirmation.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
    The document only requires review for media type definition and allocation. A first level of review has been conducted by a media types designated expert.


(13) Have all references within this document been identified as either normative or informative?
    Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
    There are two normative references to external Chromium documentation, which is not subject to IETF change control. 


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
    No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
    Publication of this document will not change the status of any document. This is correctly identified in the title page header.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
    This document does not define any protocol extension.  The newly created IANA registry includes a detailed specification of the initial contents for the registry, and a reasonable name for the new registry has been suggested.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
    No new registries are created by this document.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
    This is not applicable.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
    This is not applicable.

The following Last Call announcement was sent out (ends 2022-09-01):

From: The IESG
To: IETF-Announce
CC: draft-zern-webp@ietf.org, shodoco@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (WebP Image Format Media Type Registration) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'WebP Image Format Media Type Registration'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-09-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

This is a second Last Call for this document due to substantive changes
since the previous version.

Abstract


  This document provides the Media Type Registration for the subtype
  image/webp.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-zern-webp/



No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-zern-webp-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the image media type registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a new registration is to be made as follows:

Name: webp
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-10-21):

From: The IESG
To: IETF-Announce
CC: draft-zern-webp@ietf.org, shodoco@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (WebP Image Format Media Type Registration) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'WebP Image Format Media Type Registration'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-10-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  WebP is a RIFF-based image file format which supports lossless and
  lossy compression as well as alpha (transparency) and animation.  It
  covers use cases similar to JPEG, PNG and GIF.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-zern-webp/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    This document requests Informational status.  This is not the product of a working group, and the technical work was developed outside of the IETF.  The document’s main purpose is to provide a stable reference and make a standard media type registration.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
    This document provides references for the WebP image format, and considers its registration of the media type image/webp.

Working Group Summary:
    The document is not a product of a working group, and is sponsored by an Area Director.  Discussion has occurred on the DISPATCH and MEDIA-TYPES lists.

Document Quality:
    The document is very brief as it only requests registration for media type image/webp.  Several people have reviewed it and provided useful feedback.

Personnel:
  Document Shepherd: Huapeng Zhou
  Responsible Area Director: Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    The shepherd did a review of the document and feels it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
    The shepherd does not have any concerns about the level of reviews performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
    The document does not require any particular reviews, given its main purpose of media type registration.  It has had a preliminary review by a media types designated expert.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
    The shepherd does not have any concern or issue with this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
    The sole author has confirmed the above.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
    No IPR disclosure has been filed referencing that document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
    The document is not a product of a working group, but rather is being sponsored by an Area Director.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
    No one has threatened to appeal.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
    All the nits identified by the shepherd have been addressed.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
    The document only requires review for media type allocation. A first level of review has been conducted by a media types designated expert.


(13) Have all references within this document been identified as either normative or informative?
    Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
    There are two normative references to external Google documentation, which is not subject to IETF change control.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
    No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
    Publication of this document will not change the status of any document. This is correctly identified in the title page header.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
    This document does not define any protocol extension.  The newly created IANA registry includes a detailed specification of the initial contents for the registry, and a reasonable name for the new registry has been suggested.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
    No new registries are created by this document.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
    This is not applicable.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
    This is not applicable.