Re: Éric Vyncke's No Objection on draft-ietf-httpbis-compression-dictionary-09: (with COMMENT)

Thank you. I have an update in-flight with the edits (working on the better
intro examples) but there were a few that I'm not sure need doc changes
that I wanted to respond to (just in case they do, in fact, need updates to
the doc):

> ## Section 4
>
> As draft-vandevenne-shared-brotli-format has expired for more than a year
(and
> not even WG adopted), I wonder whether this section is still useful ?
I.e.,
> just keep section 5 and remove section 4.

The draft expired and wasn't adopted but is the format that the brotli team
(and tooling) shipped for dictionary-based compression. I asked the team to
see if they could push the draft forward as an informational RFC but I
figured it was better to have a detailed file format spec available than to
leave it out.

> Is there a reason why the lengths of the magic number are different for
the two
> supported compressions ?

The ZStandard magic number is longer because it uses an existing framing
structure of ZStandard where a 4-byte frame type and 4-byte frame length
allow for defining a "skippable frame" that is backwards-compatible with
existing ZStandard code without having to do any preprocessing to skip the
header (where brotli doesn't have similar support so a smaller, custom
header was used).

> ## Section 8
> Should `middle-boxes` be more descriptive (e.g., web proxies, ...) ?

I could list some examples but we have seen a lot of issues with devices
you might not normally think about (IDS systems that passively monitor
traffic as it passes is a painfully common one). I could put in a sample
list but it wouldn't be exhaustive.

Thanks,

-Pat

On Mon, Aug 12, 2024 at 7:40 AM Éric Vyncke via Datatracker <
noreply@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-httpbis-compression-dictionary-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-httpbis-compression-dictionary-09
>
> Thank you for the work put into this document. Please note that I am
> outside my
> area of expertise when reading this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Mark Nottingham for the shepherd's detailed write-up
> including the WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Introduction
>
> Suggest adding some (graphical?) explanations on how the technique works.
> It
> took me a while (admitting that I am not familiar with the domain) to
> understand how the headers are used. In other words, it would be nice to
> present the forest before describing the trees.
>
> ## Section 1
>
> Is it "file" or "page/resource" in `Using a previous version of a file as a
> dictionary for a newer version ` ?
>
> ## Section 2.1.3
>
> It is unclear to me how `when the dictionary is advertised as being
> available`
> can be verified by the client.
>
> ## Section 2.3
>
> I have hard time to fit the example with `The "Dictionary-ID" request
> header
> ... MUST be identical to the server-provided "id".` as there is a prefix:
> `/v1/main.js`. This is of course due to structured field, but it would be
> nice
> to explain the structure of this field.
>
> ## Section 4
>
> As draft-vandevenne-shared-brotli-format has expired for more than a year
> (and
> not even WG adopted), I wonder whether this section is still useful ? I.e.,
> just keep section 5 and remove section 4.
>
> Is there a reason why the lengths of the magic number are different for
> the two
> supported compressions ?
>
> ## Section 7.1
>
> Suggest referring to the IANA registry by their URI (i.e.,
>
> https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding
> )
> rather than by the RFC that has created them.
>
> ## Section 8
>
> Should `middle-boxes` be more descriptive (e.g., web proxies, ...) ?
>
> # NITS (non-blocking / cosmetic)
>
> ## Section 2.1.4
>
> Suggest to use double quotes around raw in `and defaults to raw`.
>
> ## Section 4
>
> s/fixed 4 byte sequence and a 32 byte hash/fixed 4-byte sequence and a
> 32-byte
> hash/ ?
>
> s/Bytes/bytes/ ?
>
>
>
>
>