Last Call Review of draft-ietf-httpbis-compression-dictionary-08
review-ietf-httpbis-compression-dictionary-08-genart-lc-enghardt-2024-08-05-00
Request | Review of | draft-ietf-httpbis-compression-dictionary |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2024-08-06 | |
Requested | 2024-07-23 | |
Authors | Patrick Meenan , Yoav Weiss | |
I-D last updated | 2024-08-05 | |
Completed reviews |
Artart Last Call review of -16
by Darrel Miller
(diff)
Genart Last Call review of -08 by Reese Enghardt (diff) Secdir Last Call review of -09 by Nancy Cam-Winget (diff) |
|
Assignment | Reviewer | Reese Enghardt |
State | Completed | |
Request | Last Call review on draft-ietf-httpbis-compression-dictionary by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/IOOONKiY1K8jyBNYetgKiMLCrEA | |
Reviewed revision | 08 (document currently at 19) | |
Result | Ready w/nits | |
Completed | 2024-08-05 |
review-ietf-httpbis-compression-dictionary-08-genart-lc-enghardt-2024-08-05-00
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.