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

Thanks, I just published draft 10 which should have addressed all of the
comments and nits:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/10/

The biggest change was calling out the two main use cases in the
introduction with diagrams showing how they would work.

There were a few comments that I wanted to call out specifically:

> ## Section 2.1.3
>
> It is unclear to me how `when the dictionary is advertised as being
available`
> can be verified by the client.

Sorry, I cleaned up the text here and linked it to the
"Available-Dictionary" section where the client makes the decision to
advertise a dictionary as being available. Hopefully that helps clear it up.

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

There's no structure to the field, it is an opaque string as far as the
client is concerned. I probably go too fancy by including a cache key and
hash as an example of the kind of string a CDN might want to use so I
simplified it to just "dictionary-12345" so hopefully it is less likely to
imply that there is any special meaning to the contents.

Everything else should be pretty straightforward from the diffs and was
mostly cleaning up the existing language.

On Wed, Aug 14, 2024 at 7:20 AM Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> Patrick
>
>
>
> Thanks for your reply, the changes, and the explanations about the text
> choices.
>
>
>
> Middlebox is an overloaded and ill-defined term at the IETF, so, add some
> examples of the most obvious use cases (making it clear that it is not
> exhaustive)
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Patrick Meenan <patmeenan@gmail.com>
> *Date: *Tuesday, 13 August 2024 at 19:29
> *To: *Eric Vyncke (evyncke) <evyncke@cisco.com>
> *Cc: *The IESG <iesg@ietf.org>,
> draft-ietf-httpbis-compression-dictionary@ietf.org <
> draft-ietf-httpbis-compression-dictionary@ietf.org>,
> httpbis-chairs@ietf.org <httpbis-chairs@ietf.org>, ietf-http-wg@w3.org <
> ietf-http-wg@w3.org>, mnot@mnot.net <mnot@mnot.net>
> *Subject: *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/ ?
>
>
>
>