Zstandard Compression and the 'application/zstd' Media Type
draft-kucherawy-rfc8478bis-06

Please review and respond to Daniel Migault SECDIR review.

Thank you for the work put into this document. And, I like the fact that the authors put in evidence in the abstract that it is NOT a standard document from the IETF. Albeit I wonder why this document is not requested to be pubslished as a standard.

Due to too many documents for this telechat (and one week of vacations to be honest...), I am balloting "No objection" trusting the ballots of my IESG colleagues/friends. I only quickly browsed the document with my internet area glasses. 

Nevertheless, please find below some non-blocking COMMENTs  and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==


== COMMENTS ==

-- Section 3.1.1 --
May I suggest to use the wording "0 or 4 bytes" rather than "0-4 bytes" for the Content_Checksum? The former hints to have a variable length between 0 and 4 bytes long.

-- Section 3.1.1.1. --
To be honest (possibly because of my quick browse), I fail to understand why the frame header has a minimum size of 2 bytes while all fields are optional except for the 1-byte Frame_Header_Descriptor ?


== NITS ==

A couple of nits, like in section 3.1.1.3.1.1. where the values 00, 10, ... should be identified as binary values.

Please respond to the secdir review.

The guidance in Section 3.1.1.2.3 (of RFC 8478; now Section 3.1.1.2.4 of
the -03) to send a Raw Block if compression would result in exceeding
the maximum size seems like it might be worth retaining.

[I did a fairly thorough review of what became RFC 8478, so here I
mostly just look at the diff.]

Section 1

   This document describes the Zstandard format.  Also, to enable the
   transport of a data object compressed with Zstandard, this document
   registers a media type that can be used to identify such content when
   it is used in a payload encoded using Multipurpose Internet Mail
   Extensions (MIME).

It also registers a media-type structured syntax suffix.

Section 6

It's a little weird to have a "Section 6 -- Use of Dictionaries" and a
"Section 7.4 --Dictionaries" that have fairly related content.

   Provisioning for use of dictionaries with zstd is planned for future
   work.  To ensure compatibility with the future specification of use

Is this planned to involve widely-distributed and well-known
dictionaries, or a more localized provisioning process (or both)?  It
might be worth clarifying.

Section 7

I'd consider "has updated the reference field for two previously
existing registrations and made one new registration".

Section 9

Are there additional implementations that are worth mentioning now that
almost a couple years have passed?

Acknowledgments

It may be worth retaining the acknowledgments from RFC 8478 with a note
of their provenance, given how little has changed since then.

I only had time to quickly review the diff which seems fine...