Re: Genart last call review of draft-ietf-httpbis-compression-dictionary-08

[Patrick Meenan <[e-mail]>]

Thank you. draft-09 has been released with the suggested updates:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/09/

Mostly some added explanations but good catch on the one-year expiration.
That was leftover from earlier drafts when the dictionaries had
expiration independent of the HTTP caching and shouldn't have been there
(and has been removed).

On Mon, Aug 5, 2024 at 12:28 PM Reese Enghardt via Datatracker <
[e-mail]> wrote:

> Reviewer: Reese Enghardt
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-httpbis-compression-dictionary-08
> Reviewer: Reese Enghardt
> Review Date: 2024-08-05
> IETF LC End Date: 2024-08-06
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is concise and to the point. I just have a few
> suggestions for clarifications.
>
> Major issues: None.
>
> Minor issues:
>
> Section 1:
>
> What is the motivation for this work? Increased efficiency relative to
> other
> compression schemas, or is there more to it? Please consider adding a
> sentence
> or two.
>
> What versions of HTTP does this document apply to? I might have missed
> something that makes it so that a statement of versioning is not needed.
> But
> otherwise, please consider adding a statement about this.
>
> Section 2.1.1:
>
> "The following algorithm will return TRUE for a valid match pattern and
> FALSE
> for an invalid pattern that MUST NOT be used"
>
> Please consider adding one sentence of motivation or clarification for the
> algorithm - IIUC it enforces the Same Origin Policy. I think explaining
> this
> motivation briefly here would make the algorithm easier to follow.
>
> Section 2.1.5.2:
>
> "Would match main.js in any directory under /app/ and expiring as a
> dictionary
> in one year."
>
> This is the first time the document mentions expiration as a concept. How
> is
> expiration specified in this example - I don't see it specified
> explicitly, so
> is one year the default? Please consider adding a clarification.
>
> Nits/editorial comments: None.
>
>
>
>