[Gen-art] Re: Genart last call review of draft-ietf-httpbis-compression-dictionary-08

[Reese Enghardt <[e-mail]>]

Thank you Patrick, the changes look good to me.

Best,
Reese


On 8/5/24 10:45, Patrick Meenan wrote:
> 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 <http://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.
>
>
>