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

Thanks. The AASVG diagrams look a lot cleaner in the HTML rendering. I also
made them look more like the flow diagrams in some of the other HTTP specs
(eliminated the blocky client and server boxes).

https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/11/

On Thu, Aug 15, 2024 at 2:16 AM Eric Vyncke (evyncke) <evyncke=
40cisco.com@dmarc.ietf.org> wrote:

> Patrick
>
>
>
> Thanks again for the revised I-D, with the new section 1.1 (with the
> diagrams), the I-D is much clearer IMHO.
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> PS: please allow me to tease you with AASVG
> https://github.com/martinthomson/aasvg especially if you use the Markdown
> format for the I-D 😊
>
>
>
> *From: *Patrick Meenan <pmeenan=40google.com@dmarc.ietf.org>
> *Date: *Wednesday, 14 August 2024 at 22:50
> *To: *Eric Vyncke (evyncke) <evyncke@cisco.com>
> *Cc: *Patrick Meenan <patmeenan@gmail.com>, 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)
>
> 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/ ?
>
>
>